Forem: Danny Holloran

Svelte 5 Runes: Reactive State That Actually Makes Sense

Danny Holloran — Mon, 25 May 2026 23:32:18 +0000

Originally published on danholloran.me

If you've ever wrestled with Svelte 4's reactive declarations — that vaguely magical $: syntax that sometimes works exactly as you expect and sometimes very much doesn't — you'll appreciate what Svelte 5 brings to the table. Runes are a new set of explicit reactive primitives that replace the old implicit system, and they're a genuine improvement: clearer, more predictable, and no longer confined to .svelte files.

What Are Runes?

Runes are compiler-recognized functions prefixed with $. Think of them as signals — they tell Svelte's compiler (and now its runtime) where reactivity lives and how it flows. Svelte 5 ships four core runes: $state, $derived, $effect, and $props. Each one is a focused primitive with clear semantics.

In Svelte 4, you'd write something like this to declare reactive state:

<script>
  let count = 0;
  $: doubled = count * 2;
</script>

That $: label is a reactive declaration — Svelte's compiler turns it into something reactive under the hood. It works, but it's implicit. The reactivity is tied to the compiler, which means it only works inside .svelte files, and its behavior in complex expressions can catch you off guard.

In Svelte 5, the same thing looks like this:

<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

Explicit, readable, and — crucially — portable.

$state, $derived, and $effect in Practice

$state replaces bare let declarations for reactive variables. It signals to Svelte that this value should be tracked. When it changes, anything that depends on it updates.

$derived replaces $: someValue = .... It computes a value from reactive dependencies and is memoized — it only recalculates when its inputs change.

$effect replaces $: { ... } blocks that had side effects. It runs after the DOM has updated, and it re-runs whenever its reactive dependencies change. It also accepts a return value for cleanup — no more worrying about stale subscriptions:

<script>
  let query = $state('');
  let results = $state([]);

  $effect(() => {
    if (!query) {
      results = [];
      return;
    }

    const controller = new AbortController();
    fetch(`/api/search?q=${query}`, { signal: controller.signal })
      .then(r => r.json())
      .then(data => { results = data; });

    // cleanup runs before the next effect
    return () => controller.abort();
  });
</script>

For derived values that need more than a single expression, $derived.by accepts a function:

<script>
  let items = $state([1, 2, 3, 4, 5]);
  let stats = $derived.by(() => {
    const sum = items.reduce((a, b) => a + b, 0);
    return { sum, avg: sum / items.length };
  });
</script>

<p>Average: {stats.avg}</p>

Sharing State Across Components

This is where things get genuinely exciting. In Svelte 4, sharing reactive state meant reaching for Svelte stores — writable, readable, derived — and using the $ shorthand to auto-subscribe. Stores still work in Svelte 5, but runes give you a simpler option: reactive state in .svelte.ts files.

Any file ending in .svelte.ts (or .svelte.js) gets the runes compiler. That means $state and $derived work outside of components:

// cart.svelte.ts
function createCart() {
  let items = $state<{ name: string; price: number }[]>([]);

  let total = $derived(items.reduce((sum, item) => sum + item.price, 0));

  function add(item: { name: string; price: number }) {
    items = [...items, item];
  }

  function remove(index: number) {
    items = items.filter((_, i) => i !== index);
  }

  return {
    get items() {
      return items;
    },
    get total() {
      return total;
    },
    add,
    remove,
  };
}

export const cart = createCart();

Then in any component:

<script>
  import { cart } from '$lib/cart.svelte.ts';
</script>

<p>Total: ${cart.total.toFixed(2)}</p>
<button onclick={() => cart.add({ name: 'Widget', price: 9.99 })}>
  Add to cart
</button>

One key thing to note: export an object or function — not a raw $state variable directly. Exporting a primitive breaks the reactivity because the value gets "frozen" at import time. The getter pattern above (get items()) keeps the reference live.

Also worth knowing: if you're using SSR, shared module-level $state is shared across all server requests. Scope it inside a function (like the factory pattern above) or use getContext for per-request isolation.

Worth Trying

Svelte 5's runes aren't just a syntax facelift — they're a more honest model of how reactivity works. The old magic is replaced with explicit primitives that behave consistently whether you're in a component or a shared module. If you're starting a new Svelte project, go runes-first. If you're on an existing codebase, the migration is gradual — Svelte 5 runs Svelte 4 components without changes.

The official migration guide is thorough and a solid starting point. The LogRocket deep dive is also worth bookmarking for when you hit an edge case.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

React Compiler v1.0: Automatic Memoization Without the Headache

Danny Holloran — Mon, 25 May 2026 23:32:14 +0000

Originally published on danholloran.me

If you've spent any time tuning a React app for performance, you know the ritual: wrap callbacks in useCallback, memoize expensive calculations with useMemo, slap React.memo on child components that keep re-rendering for no good reason. It works — but it's also brittle, easy to get wrong, and clutters your components with optimization noise that has nothing to do with what the component is actually supposed to do.

React Compiler v1.0 shipped in October 2025, and it tackles this problem at the build step. Instead of you manually annotating what needs to be memoized, the compiler analyzes your component code, figures it out, and handles it automatically. Meta has been running it in production for a while now and reported a 20–30% reduction in render time across their apps. It's time to take it seriously.

What the Compiler Actually Does

React Compiler is a Babel (or SWC) plugin that runs at build time and transforms your component code. It classifies every expression in a component as either static — values that never change between renders — or dynamic — values that may change. From there it automatically injects the memoization equivalents of useMemo, useCallback, and React.memo exactly where they're needed, including in places where you can't manually memoize, like conditionally computed values.

The result is that components you write as plain, idiomatic React get compiled into components that behave as if a very careful engineer went through and added memoization in all the right places.

Here's a before/after to make it concrete. Before the compiler, you might write something like this to avoid unnecessary re-renders:

import { useCallback, useMemo, memo } from "react";

const ProductCard = memo(({ product, onAddToCart }) => {
  const formattedPrice = useMemo(
    () =>
      new Intl.NumberFormat("en-US", {
        style: "currency",
        currency: "USD",
      }).format(product.price),
    [product.price],
  );

  const handleClick = useCallback(() => {
    onAddToCart(product.id);
  }, [onAddToCart, product.id]);

  return (
    <div className="card">
      <h2>{product.name}</h2>
      <p>{formattedPrice}</p>
      <button onClick={handleClick}>Add to Cart</button>
    </div>
  );
});

With React Compiler, you write the plain version and the compiler handles the memoization for you:

// No memo(), no useMemo, no useCallback — the compiler adds the equivalent automatically
const ProductCard = ({ product, onAddToCart }) => {
  const formattedPrice = new Intl.NumberFormat("en-US", {
    style: "currency",
    currency: "USD",
  }).format(product.price);

  const handleClick = () => {
    onAddToCart(product.id);
  };

  return (
    <div className="card">
      <h2>{product.name}</h2>
      <p>{formattedPrice}</p>
      <button onClick={handleClick}>Add to Cart</button>
    </div>
  );
};

Same runtime behavior, significantly less ceremony.

Setting It Up

Getting the compiler running is straightforward for most setups. If you're on Next.js 15+, it's a single config flag:

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  reactCompiler: true,
};

export default nextConfig;

For Vite projects, install the Babel plugin and add it to your Vite config:

npm install --save-dev babel-plugin-react-compiler

// vite.config.js
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: ["babel-plugin-react-compiler"],
      },
    }),
  ],
});

One thing to know: the compiler requires your code to follow the Rules of React — things like not mutating state directly and keeping components pure. If a component violates these rules, the compiler skips it rather than producing broken output. You can also explicitly opt a component out with a "use no memo" directive at the top of the function body when you need manual control.

Caveats and What to Watch For

The compiler is stable and production-ready, but it's not a complete free pass on performance thinking. A few things worth keeping in mind:

It requires valid React code. The compiler performs static analysis, so components that mutate props, rely on side effects in render, or break referential equality in surprising ways won't always compile cleanly. Running eslint-plugin-react-compiler alongside the build plugin will flag these before they become silent issues.

useMemo and useCallback still have a role as escape hatches. When a memoized value is used as a useEffect dependency and you need precise control over when the effect fires, manually specifying that dependency is still valid and the compiler won't fight you on it.

Check your bundle output once. Tools like React DevTools show you whether a component has been compiled (it'll show "Memo ✓" in the component tree). A quick audit after enabling the compiler confirms it's actually optimizing the components you expect.

React Compiler doesn't change how you think about component design — it just removes the tax of manually annotating your performance constraints. For most React codebases, enabling it today is a straightforward win.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

TypeScript 7.0: The Go Compiler That Makes TS 10x Faster

Danny Holloran — Mon, 25 May 2026 23:23:07 +0000

Originally published on danholloran.me

If you've worked on a large TypeScript codebase, you know the pain. You hit save, you wait. The type-checker grinds through hundreds of files, your IDE lag spikes, and CI takes minutes just to get through tsc --noEmit. It's not TypeScript's fault — the language has always made a reasonable trade-off between expressiveness and performance. But that trade-off is about to get renegotiated.

TypeScript 7.0 is currently in beta, and the headlining change is a complete rewrite of the compiler — from TypeScript itself to Go. The result is build times that are roughly 10x faster. Not 10% faster. Ten times.

Why Go, and Why Now

The TypeScript team's choice of Go wasn't about hype — it was about constraints. The existing compiler is JavaScript running on Node.js, which means it inherits V8's garbage collector and single-threaded execution model. That's fine for small projects, but as codebases scale to hundreds of thousands of lines, GC pauses and sequential file processing become the bottleneck.

Go hits a practical sweet spot: it compiles to native binaries (eliminating Node.js startup overhead), its goroutines make parallelizing across files straightforward, and its memory model is substantially more predictable than V8's heap. In benchmarks using the VS Code codebase — 1.5 million lines of TypeScript — the difference is stark:

tsc (current):    ~78 seconds
tsgo (TS 7 beta):  ~7.5 seconds

Memory consumption also drops by around 57%. If you run type-checking in CI on every PR, that's real money and real developer-hours back on the table.

Trying It Today

TypeScript 7.0 is still in beta, but it's stable enough for experimentation and, for many projects, everyday use. The beta ships under the @typescript/native-preview package:

# Local dev dependency
npm install -D @typescript/native-preview

# Or globally
npm install -g @typescript/native-preview

Once installed, you get a tsgo executable that works as a drop-in for tsc:

# Type-check your project
tsgo --noEmit

# Watch mode
tsgo --watch

# Check the version
tsgo --version
# Version 7.0.0-beta

VS Code users can also install the TypeScript Native Preview extension to get the faster language server in the editor. The experience is noticeably snappier even on mid-sized codebases — hover types and go-to-definition feel instant compared to the current server.

What's Different (and What Might Break)

For the vast majority of projects, tsgo is a transparent swap for tsc. As of the beta, the Go compiler passes over 95% of the TypeScript test suite. The remaining gaps are mostly around legacy emit modes and decorator metadata, which modern projects typically don't rely on.

There are two notable changes to be aware of:

Strict mode is now the default. TypeScript 7 enables strict: true out of the box, which bundles strictNullChecks, noImplicitAny, and friends. If your tsconfig.json currently omits strict settings, you may see new errors in the beta. The fix is explicit:

{
  "compilerOptions": {
    "strict": false
  }
}

That said, if you've been meaning to tighten up your config, this is a good forcing function.

Some tooling APIs aren't compatible yet. The compiler exposes a different internal API surface (codenamed Strada). Third-party tools that reach into TypeScript's compiler internals — some linters, formatters, or custom language service plugins — may not work with tsgo until they're updated. Check your dependencies before switching production CI over. For most teams using tsc directly or through tools like ts-jest and tsx, the transition should be smooth.

What This Means Going Forward

TypeScript 7 isn't adding a sweeping new type system feature — it's investing in the foundation. Faster type-checking compounds in every direction: tighter feedback loops in the editor, faster CI pipelines, and more room for the language to add richer checks without hitting practical performance walls.

The stable release is expected by late June or early July 2026. Until then, the beta is worth running on a branch or a greenfield project to get a feel for the speedups. You can follow along at the TypeScript blog and file issues on the typescript-go GitHub repo.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

Connecting Wallets the Right Way: wagmi v2 and EIP-6963

Danny Holloran — Mon, 25 May 2026 23:23:03 +0000

Originally published on danholloran.me

If you've ever built a dApp and had a user complain that "your site only shows MetaMask even though I have Coinbase Wallet installed," you've run headfirst into the window.ethereum problem. For years, every wallet browser extension raced to claim the same global, and whichever one loaded last won. The result was a constant arms race between wallet vendors and a genuinely terrible user experience.

EIP-6963 fixed that — and wagmi v2 makes the fix trivially easy to adopt. If you're still rolling your own wallet detection or using a library that hasn't caught up yet, this post is for you.

The window.ethereum Problem and How EIP-6963 Solves It

The original EIP-1193 standard gave wallets a single attachment point: window.ethereum. One slot, many wallets, inevitable collisions. MetaMask and Coinbase Wallet both inject themselves there; whoever ran last overwrites the other.

EIP-6963 introduces an event-based discovery protocol instead. On page load, your dApp fires a eip6963:requestProvider event. Each installed wallet extension that supports the spec responds by emitting an eip6963:announceProvider event carrying its own provider object and metadata (icon, name, RDNS identifier). Your app collects the responses and builds a list — every wallet, no conflicts.

You can implement this yourself, but the raw event wiring is boilerplate you don't need to own:

// Low-level EIP-6963 — illustrative only, use wagmi instead
const providers: EIP6963ProviderDetail[] = [];

window.addEventListener("eip6963:announceProvider", (event: CustomEvent) => {
  providers.push(event.detail);
});

window.dispatchEvent(new Event("eip6963:requestProvider"));

The real-world issue is that you also need to handle providers announced after your request, de-duplicate by RDNS, manage lifecycle — it adds up. wagmi v2 handles all of it.

Setting Up wagmi v2 with Multi-Wallet Support

wagmi v2 replaced its ethers.js dependency with viem — a lightweight, fully typed Ethereum library — and rebuilt its connector system from scratch. EIP-6963 discovery is enabled by default with the injected() connector.

Install the stack:

npm install wagmi viem @tanstack/react-query

Create your config:

// lib/wagmi.ts
import { createConfig, http } from "wagmi";
import { mainnet, sepolia } from "wagmi/chains";
import { injected, walletConnect, coinbaseWallet } from "wagmi/connectors";

export const config = createConfig({
  chains: [mainnet, sepolia],
  connectors: [
    injected(), // discovers ALL EIP-6963 wallets automatically
    walletConnect({ projectId: import.meta.env.VITE_WC_PROJECT_ID }),
    coinbaseWallet({ appName: "My dApp" }),
  ],
  transports: {
    [mainnet.id]: http(),
    [sepolia.id]: http(),
  },
});

Wrap your app with the providers:

// main.tsx
import { WagmiProvider } from "wagmi";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { config } from "./lib/wagmi";

const queryClient = new QueryClient();

export function App() {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={queryClient}>
        <YourApp />
      </QueryClientProvider>
    </WagmiProvider>
  );
}

That injected() connector does the EIP-6963 legwork automatically. When a user has three wallets installed, your connection UI will show all three.

Building a Wallet Connection Component

With the config in place, wagmi's hooks give you everything you need. Here's a minimal but fully functional wallet picker:

// components/WalletConnect.tsx
import { useConnect, useAccount, useDisconnect, useBalance } from "wagmi";
import { formatEther } from "viem";

export function WalletConnect() {
  const { connectors, connect, isPending } = useConnect();
  const { address, isConnected, chain } = useAccount();
  const { disconnect } = useDisconnect();
  const { data: balance } = useBalance({ address });

  if (isConnected && address) {
    return (
      <div>
        <p>
          {address.slice(0, 6)}…{address.slice(-4)} on {chain?.name}
        </p>
        {balance && (
          <p>{parseFloat(formatEther(balance.value)).toFixed(4)} ETH</p>
        )}
        <button onClick={() => disconnect()}>Disconnect</button>
      </div>
    );
  }

  return (
    <div>
      {connectors.map((connector) => (
        <button
          key={connector.uid}
          onClick={() => connect({ connector })}
          disabled={isPending}
        >
          {connector.name}
        </button>
      ))}
    </div>
  );
}

A few things worth noting here. connectors is populated at runtime based on what's actually available in the browser — if the user has MetaMask and Phantom installed, both show up. The connector.uid is stable across renders so it's safe as a React key. And useBalance returns a bigint value, which is where viem's formatEther utility comes in — it handles the wei-to-ether conversion without floating-point surprises.

For sending transactions, viem's type-safe primitives plug directly into wagmi's useSendTransaction hook:

import { useSendTransaction } from "wagmi";
import { parseEther } from "viem";

const { sendTransaction } = useSendTransaction();

sendTransaction({
  to: "0xRecipientAddress",
  value: parseEther("0.01"),
});

Where This Lands in Practice

EIP-6963 browser support is now effectively universal among modern wallet extensions — MetaMask, Coinbase Wallet, Phantom, Rabby, and most others have shipped it. Users with multiple wallets get a proper choice UI instead of a silent clobber. wagmi v2's default injected() connector handles the discovery without any extra configuration on your end.

If you're maintaining an older dApp that still reaches for window.ethereum directly, migrating to wagmi v2 is the cleanest upgrade path. The wagmi docs are thorough, and the TypeScript types throughout viem make the contract interactions significantly less error-prone than working with ethers.js or raw JSON-RPC calls.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

CSS Scroll-Driven Animations: No JavaScript Required

Danny Holloran — Mon, 25 May 2026 23:14:19 +0000

Originally published on danholloran.me

If you've ever added a scroll progress bar to a page or built a "reveal on scroll" effect, you've probably reached for Intersection Observer, a scroll event listener, or a library like GSAP. They work fine, but they run on the main thread, add weight to your bundle, and often require careful cleanup. The browser has a better idea.

CSS scroll-driven animations are now stable across Chrome, Edge, and Safari 18, with Firefox catching up fast. They let you tie CSS animations directly to scroll position — no JavaScript involved. The result is compositor-thread animations that stay buttery-smooth even when your main thread is busy.

The Two Timeline Types

The core of the API is the animation-timeline property, which replaces the default time-based animation timeline with a scroll-based one. There are two flavors: scroll() and view().

scroll() tracks how far a scroll container has been scrolled from top (0%) to bottom (100%). It's the right tool for things that should reflect the document's overall scroll progress — like a reading progress bar.

@keyframes grow-bar {
  from {
    transform: scaleX(0);
  }
  to {
    transform: scaleX(1);
  }
}

.progress-bar {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 4px;
  background: oklch(60% 0.2 250);
  transform-origin: left;

  animation: grow-bar linear;
  animation-timeline: scroll(root block);
  animation-fill-mode: both;
}

That's it. scroll(root block) tells the browser to use the root scrolling container's block (vertical) axis as the timeline. No scroll listeners. No requestAnimationFrame. The browser handles it entirely at the compositor level.

view() tracks an element's visibility within its scroll container as it enters and exits the viewport. It's purpose-built for reveal animations — animating each card or section as it scrolls into view.

@keyframes fade-up {
  from {
    opacity: 0;
    translate: 0 40px;
  }
  to {
    opacity: 1;
    translate: 0 0;
  }
}

.card {
  animation: fade-up linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 40%;
}

The animation-range property is the secret weapon here. It lets you specify which phase of the element's journey through the viewport should drive the animation. entry 0% entry 40% means "animate during the first 40% of the element's entrance into the viewport" — a crisp reveal that finishes before the element is fully on screen.

Scroll-Triggered Animations (Chrome 145+)

There's a newer addition worth knowing about: scroll-triggered animations. Unlike scroll-driven animations (which continuously update based on position), scroll-triggered animations fire once when a scroll threshold is crossed — similar to IntersectionObserver, but declarative in CSS.

@keyframes highlight-nav {
  to {
    background: oklch(25% 0 0);
    box-shadow: 0 2px 12px oklch(0% 0 0 / 30%);
  }
}

header {
  animation: highlight-nav linear forwards;
  animation-timeline: scroll(root);
  animation-range: 80px 81px;
}

This changes the header background once the user has scrolled past 80px and holds that state. It's a one-liner replacement for the classic sticky-nav-scroll-listener pattern.

Progressive Enhancement

Browser support is solid but not universal — Firefox still has partial support behind a flag. Always wrap scroll-driven animations in a @supports check so the experience degrades gracefully:

@supports (animation-timeline: scroll()) {
  .progress-bar {
    animation: grow-bar linear;
    animation-timeline: scroll(root block);
    animation-fill-mode: both;
  }
}

Without the @supports guard, browsers that don't understand animation-timeline will simply ignore those declarations. For the progress bar case that's fine — no bar is better than a broken one. For critical reveal animations, ensure elements are visible by default and only animate them when the feature is supported.

When to Reach for This

Scroll-driven animations shine when the effect is purely visual and directly tied to scroll position: reading indicators, sticky header transitions, parallax backgrounds, element reveals, and image carousels. For anything that needs to trigger side effects — updating state, fetching data, analytics events — you still want Intersection Observer or a scroll event. CSS animations can't call your JavaScript.

MDN's scroll-driven animations guide is the most complete reference, and scroll-driven-animations.style has a fantastic playground of real-world examples to steal from. Give it a scroll.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

Vite 8 + Rolldown: Rust-Powered Builds That Are 10–30x Faster

Danny Holloran — Mon, 25 May 2026 23:14:14 +0000

Originally published on danholloran.me

If you've ever watched a production build spin for a minute while your terminal mocks you with its progress bar, Vite 8's arrival is worth paying attention to. The headline change is a new bundler under the hood — Rolldown — and the performance numbers coming out of early adopters are hard to ignore.

Why Vite Needed a New Bundler

For years, Vite juggled two separate bundlers to cover different scenarios. During development it leaned on esbuild for its raw speed, and at build time it handed off to Rollup for its sophisticated chunking and plugin ecosystem. This split worked well enough, but it created a persistent headache: the two pipelines didn't always behave the same way. You'd write a plugin that worked in dev, only to hit a subtle edge case in production. Or you'd track down a build inconsistency that turned out to be a difference in how esbuild and Rollup resolved a module. The glue code holding everything together kept growing.

Rolldown solves this by being a single bundler that handles both jobs. It's written in Rust (hence the speed), it supports the Rollup plugin API, and it's built by the VoidZero team — the same people who maintain Vite. The goal was a unified toolchain: Vite for orchestration, Rolldown for bundling, and Oxc for parsing, transforming, and linting, all from one team.

What the Numbers Actually Look Like

The benchmarks aren't theoretical. Teams migrating to rolldown-vite (the technical preview that shipped before Vite 8) reported some striking results:

Linear cut production build times from 46 seconds to 6 seconds
Beehiiv reduced their build time by 64%
Ramp saw a 57% reduction

Those kinds of improvements don't come from configuration tweaks — they come from replacing JavaScript-based bundling with native Rust code. Rolldown benchmarks at 10–30x faster than Rollup for production bundling, while matching esbuild's performance in transformation speed.

Upgrading and What Changes

The migration story is deliberately smooth. Rolldown supports the same plugin hooks as Rollup and Vite, so most projects can drop in Vite 8 without rewriting configs. There's also a compatibility layer that auto-converts existing esbuild and Rollup options to their Rolldown equivalents.

npm install vite@8

For straightforward projects, that's often the whole migration. For larger or more complex setups, the recommended path is a two-step upgrade: first move to the rolldown-vite package to isolate any Rolldown-specific issues, then upgrade to Vite 8 proper.

# Step 1: try the rolldown-vite preview
npm install rolldown-vite

# Step 2: update package.json to point to the official release
npm install vite@8

Vite 8 also ships two smaller quality-of-life features worth knowing about. First, built-in tsconfig paths resolution — enable it with resolve.tsconfigPaths: true in your Vite config and stop manually mirroring path aliases between TypeScript and Vite. Second, automatic support for TypeScript's emitDecoratorMetadata, which is a welcome relief for Angular and NestJS users who previously needed a separate plugin.

// vite.config.ts
export default defineConfig({
  resolve: {
    tsconfigPaths: true, // reads paths from tsconfig automatically
  },
});

If your project depends on a meta-framework like Nuxt, Astro, or uses Vitest, you'll need to override Vite in your package manager until those frameworks ship their own updates:

// package.json (npm)
{
  "overrides": {
    "vite": "^8.0.0"
  }
}

What's Coming Next

The Rolldown integration opens the door to features that weren't possible in the split-bundler model. Full Bundle Mode — currently experimental — promises 3× faster dev server startup and 10× fewer network requests for large projects by letting Rolldown handle the entire dev pipeline instead of serving unbundled modules. There's also ongoing work on raw AST transfer, which would let JavaScript plugins access Rolldown's Rust-produced AST with near-zero overhead, closing the performance gap between native and JS plugins.

If you haven't tried Vite 8 yet, it's worth upgrading even just to measure the build time difference on your own project. For most teams, the migration will take minutes and the payoff will be immediate. The era of waiting 45 seconds for a frontend build should finally be behind us.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.