The usual fix has been to bolt on a dedicated vector database or a hosted search service, then write a sync pipeline to keep it in step with your models. Laravel 13 removes most of that work. Vector columns, an Eloquent cast, and a whereVectorSimilarTo query builder method now ship in the framework, so semantic search can live in the database you already run.

What you need before you start ​

Vector search in Laravel 13 depends on two things. First, a database that can store and compare vectors: PostgreSQL with the pgvector extension or MariaDB 11.7 and later (MongoDB works through the Laravel MongoDB package). Second, the first-party Laravel AI SDK, which handles calling an embedding provider and turning text into arrays of numbers.

An embedding is a long array of floats, often 1,536 of them, that encodes what a piece of text means. Texts with similar meanings land close together in that space, so "budget coastal rentals" and "cheap places near the beach" end up neighbors even with zero shared words.

The migration side is short:

use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

Schema::ensureVectorExtensionExists();

Schema::create('articles', function (Blueprint $table) {
    $table->id();
    $table->foreignId('team_id')->constrained();
    $table->string('title');
    $table->text('body');
    $table->vector('embedding', dimensions: 1536)->nullable()->index();
    $table->timestamps();
});

ensureVectorExtensionExists() enables pgvector if it is not already on, and calling index() on a vector column creates an HNSW index using cosine distance. The dimensions value has to match your embedding model exactly, so 1536 for OpenAI's text-embedding-3-small. Swap models later and you are re-embedding every row, so pick deliberately.

On the model, the AsVector cast converts between PHP arrays and the database vector format:

use Illuminate\Database\Eloquent\Casts\AsVector;

protected function casts(): array
{
    return [
        'embedding' => AsVector::class,
    ];
}

Generating and storing embeddings ​

Embedding generation is a network call to a paid API, so it does not belong in a request cycle or a model saving hook. Push it to a queued job, and batch where you can. The AI SDK's Embeddings class sends many inputs in one API call:

use App\Models\Article;
use Laravel\Ai\Embeddings;

Article::whereNull('embedding')
    ->chunkById(100, function ($articles) {
        $response = Embeddings::for(
            $articles->map(fn ($a) => $a->title . "\n\n" . $a->body)->all()
        )->generate();

        foreach ($articles->values() as $i => $article) {
            $article->update(['embedding' => $response->embeddings[$i]]);
        }
    });

Embedding the title together with the body gives the vector more signal for short articles. For long documents, you will get better matches by splitting the content into chunks with their own rows and embeddings, because one vector has to summarize everything it covers.

Querying by meaning ​

With embeddings stored, the search itself is one method:

$results = Article::query()
    ->where('team_id', $user->team_id)
    ->whereVectorSimilarTo('embedding', $request->input('q'), minSimilarity: 0.4)
    ->limit(10)
    ->get();

whereVectorSimilarTo compares stored vectors using cosine similarity, drops anything below minSimilarity (a value from 0.0 to 1.0), and orders results with the closest match first. When you pass a plain string, Laravel embeds it for you with your configured provider, so the user's query goes straight in.

That convenience has a cost: every search is now an embedding API call, with the latency and per-token billing that comes with it. Turn on embedding caching in config/ai.php (caching.embeddings.cache), which keys results on provider, model, dimensions, and input and keeps them for 30 days. Popular queries then skip the network entirely.

If you need the raw numbers, the lower-level methods expose them:

$results = Article::query()
    ->select('*')
    ->selectVectorDistance('embedding', $queryEmbedding, as: 'distance')
    ->whereVectorDistanceLessThan('embedding', $queryEmbedding, maxDistance: 0.3)
    ->orderByVectorDistance('embedding', $queryEmbedding)
    ->limit(10)
    ->get();

Selecting the distance is handy while you tune thresholds. Log a few real queries with their distances and you will quickly see where relevant results stop and noise starts. A threshold copied from a blog post (including this one) is a starting guess, not a setting.

When vector search is the wrong tool ​

Semantic search is great at intent and bad at exactness. A user searching for an order number, a SKU, or an error code wants an exact match, and embeddings will happily return "similar-looking" codes. Keep whereFullText or a plain where for those cases, and consider routing queries that look like identifiers away from the vector path.

Also watch the combination of filters and approximate indexes. An HNSW index finds nearest neighbors first and your where clauses filter after, so a narrow filter like a single small team can return fewer than ten results. Newer pgvector releases add iterative index scans to help, but test with realistic data.

Laravel's search documentation also covers a hybrid pattern worth knowing: retrieve 50 candidates with fast full-text search, then reorder them with the AI SDK's rerank collection macro. For many apps that beats pure vector search on both cost and relevance. Start with the version that needs the least infrastructure, measure it against real queries, and only add moving parts when the logs say you need them.

Both work, sort of. The effect version renders nothing (or a placeholder) on the first client pass and then flips, which costs you an extra render and some layout shift. The typeof window version is worse, because it renders different output on the server and the client, which is exactly how you get a hydration mismatch. React 19.3, released in September 2026, finally ships a real answer: use(browser()).

What browser() actually does ​

browser is a new export from react-dom. You call it inside use, and it marks the component as browser-only during server rendering:

import { Suspense, use, useState } from "react";
import { browser } from "react-dom";

function SavedDraft() {
  use(browser("The draft is stored in localStorage."));

  const [draft, setDraft] = useState(() => localStorage.getItem("draft") ?? "");

  return (
    <textarea
      value={draft}
      onChange={(e) => {
        setDraft(e.target.value);
        localStorage.setItem("draft", e.target.value);
      }}
    />
  );
}

export default function Editor() {
  return (
    <Suspense fallback={<p>Loading draft...</p>}>
      <SavedDraft />
    </Suspense>
  );
}

On the server, use(browser()) stops rendering that component and leaves the nearest <Suspense> fallback in the HTML. In the browser, it returns undefined and the component renders normally. Notice that the useState initializer can read localStorage directly. There's no guard and no second render, because this code only ever runs where localStorage exists.

The mental model is the nice part. Browser-only content is now just another thing that suspends. It shares loading states with your data fetching, it composes with streaming, and it shows up in the HTML as a proper fallback instead of an empty <div> that pops in later.

A few rules from the official docs worth memorizing:

• It must sit inside a <Suspense> boundary during server rendering. Without one, the server render fails.
• It only works in Client Components. In a Server Components setup like Next.js, put it in a 'use client' file.
• Calling browser() by itself does nothing. Pass it to use, and don't throw it.

Opting out conditionally ​

Because use can be called after an early return or inside an if, you can opt out of server rendering only when you actually need to. That's something the mounted-flag pattern never handled cleanly.

import { use } from "react";
import { browser } from "react-dom";

export function useTimeZone(defaultTimeZone) {
  if (defaultTimeZone !== undefined) {
    return defaultTimeZone;
  }

  use(browser("No default time zone was provided."));
  return Intl.DateTimeFormat().resolvedOptions().timeZone;
}

If the event page passes 'America/New_York', the time zone lands in the server HTML. If it doesn't, the component suspends on the server and reads the device's zone in the browser.

The same trick works well for client-side data libraries. Wrap your query hook so it only skips SSR when there's no server-provided data:

function useBrowserQuery(key, options) {
  if (options.initialData === undefined) {
    use(browser("useBrowserQuery: no initial data was provided."));
  }
  return useQuery(key, options);
}

Now ProductDetails renders to HTML when a loader or Server Component hands it initialData, and quietly defers to the browser when it doesn't.

Seeing what bailed out, and bailing out on purpose ​

A browser bailout isn't an error, so React does not send it to onError or to hydrateRoot's onRecoverableError. Instead, the server renderers accept a new onBrowserBailout callback. The string you passed to browser() becomes the reported error's cause, and you also get a component stack:

const { pipe } = renderToPipeableStream(<App />, {
  onShellReady() {
    pipe(res);
  },
  onBrowserBailout(error, errorInfo) {
    logger.info("browser-only render", {
      reason: error.cause,
      stack: errorInfo.componentStack,
    });
  },
});

That's worth wiring up. A browser-only component is a real SEO and first-paint tradeoff, and it's easy for a team to keep adding them until half the page is fallbacks. Logging them gives you a count to watch.

The same value also works as an abort reason. If a slow Suspense boundary is holding up your stream, you can hand it off to the client instead of failing:

setTimeout(() => {
  abort(browser("The server render timed out."));
}, 10000);

Pending boundaries stay in their fallback state and finish rendering in the browser. That's a much friendlier timeout than a 500. If your rendering API takes an AbortSignal, pass browser() to AbortController.abort instead.

When not to reach for it ​

browser() makes skipping the server easy, and that's the risk. Anything inside the boundary is missing from the initial HTML, so crawlers and slow connections see your fallback. Before reaching for it, ask whether the component could render a sensible default on the server, like a saved preference from a cookie instead of localStorage, or a time zone from the request. The conditional pattern above is usually the right middle ground.

When a component truly can't render on the server, though, this is the cleanest tool React has offered. Upgrade to React 19.3, delete your useIsMounted hook, and read the React 19.3 release post for the other headline features, <ViewTransition> and Fragment Refs.

That wall is mostly gone now. Oxlint's JavaScript plugin support hit alpha in March 2026, and the Oxc team's claim is that roughly 80% of ESLint users can switch and have it "just work." The interesting part is how they got there: an ESLint-compatible plugin API running beside the native Rust rules, so you keep your rules and only pay JavaScript prices for the rules that actually need JavaScript.

Existing plugins: point at them and go ​

JS plugins are loaded through a jsPlugins array in your config. Any valid import specifier works, whether that's an npm package or a local file, and paths resolve relative to the config file.

{
  "jsPlugins": ["eslint-plugin-testing-library", "./lint/local-rules.js"],
  "rules": {
    "testing-library/no-render-in-lifecycle": "error",
    "local-rules/no-legacy-api-client": "error"
  }
}

The compatibility story is backed by numbers rather than vibes. Oxc runs its JS plugin layer against ESLint's own rule test suite (33,006 tests, 100% passing) and against popular plugins like eslint-plugin-react-hooks, ESLint Stylistic, Testing Library, and SonarJS, all at or near 100%. Plugins that aren't on that list will often work anyway, as long as they target the ESLint v9 API. Plugins still using APIs ESLint removed in v9 or earlier won't be patched up for you.

One wrinkle you'll hit quickly is name collisions. Oxlint natively implements some plugins (like jsdoc and react) but not every rule in them. Aliasing lets you use the native rules where they exist and fall back to the npm package for the rest:

{
  "jsPlugins": [{ "name": "jsdoc-js", "specifier": "eslint-plugin-jsdoc" }],
  "rules": {
    "jsdoc/require-property-description": "error",
    "jsdoc-js/check-examples": "error"
  }
}

The same trick works for ESLint core rules that Oxlint hasn't ported yet. The oxlint-plugin-eslint package ships all of ESLint's built-ins as a JS plugin under the eslint-js prefix, which is how you get no-restricted-syntax and its AST selectors back.

Writing rules: same API, one optional tweak ​

If you've written an ESLint rule before, you already know how to write an Oxlint rule. The plain create(context) shape works unchanged. Oxlint also offers an alternative createOnce API that's worth adopting for anything new:

// lint/local-rules.js
import { eslintCompatPlugin } from "@oxlint/plugins";

const noLegacyApiClient = {
  createOnce(context) {
    return {
      ImportDeclaration(node) {
        if (node.source.value === "@/lib/legacy-api") {
          context.report({
            node,
            message: "Use the generated client in @/lib/api instead.",
          });
        }
      },
    };
  },
};

export default eslintCompatPlugin({
  meta: { name: "local-rules" },
  rules: { "no-legacy-api-client": noLegacyApiClient },
});

The difference is that ESLint's create runs once per file, so the linter has to call into JavaScript just to find out which AST nodes your rule cares about. createOnce runs a single time, which lets Oxlint learn your visitor up front and, eventually, skip files that contain none of those nodes without crossing the Rust/JS boundary at all. Any per-file state moves into a before() hook. The docs are candid that this doesn't make rules faster yet; it positions them to get faster for free in later releases. And because eslintCompatPlugin adds a create shim, the same plugin still runs in plain ESLint, which matters during a gradual migration.

For tests, oxlint/plugins-dev exports a RuleTester modeled on ESLint's, and it slots into Vitest by assigning RuleTester.describe and RuleTester.it.

Migrating, and what still doesn't fit ​

The migration path is a single command against your flat config:

npx @oxlint/migrate eslint.config.js

On the Node.js repo (6,298 files, 98 JS rules including 23 custom ones) the Oxc team measured ESLint at 1 minute 43 seconds and Oxlint at 21 seconds. That 4.8x is the low end, because so much of that project's rule set still runs in JavaScript. Projects leaning on typescript-eslint see bigger wins, since type-aware linting went stable in July 2026 with 59 of typescript-eslint's 61 type-aware rules running on the Go-based TypeScript 7 compiler. Turn it on with "options": { "typeAware": true } and use oxlint --type-aware --debug timings to find out which rules are eating your lint budget.

Before you rip ESLint out, check three things:

• Vue, Svelte, and Angular templates. Custom file formats and parsers aren't supported for JS plugins yet. If your rules need to see <template> blocks, keep ESLint for those files for now.
• Custom type-aware rules. typescript-eslint's rules are built in, but your own rules can't ask the type checker anything yet.
• Slow plugins stay slow. Oxlint gives your rules a fast parser, but a plugin that hits the filesystem on every node is just as expensive here. If you lint formatting with ESLint Stylistic, moving that work to a formatter is the bigger win.

Oxlint also runs fine alongside ESLint, so the low-risk move is to let Oxlint handle everything it can and shrink your ESLint config down to the leftovers. Start with @oxlint/migrate, read what it couldn't convert, and decide from there. The JS plugins guide and writing plugins docs cover the rest.

The usual workaround is to split the query in two and fire the slow one separately. That works, but it throws away the thing you liked about GraphQL in the first place: one operation that describes one screen. @defer and @stream are the spec-track fix. They let a single query return an initial payload right away and send the slow parts later as patches.

How @defer works ​

@defer goes on a fragment spread or an inline fragment. Everything outside the deferred fragment comes back in the first payload. The fragment's fields arrive in a later payload once they resolve.

query ProductPage($id: ID!) {
  product(id: $id) {
    id
    name
    price
    ...Reviews @defer(label: "reviews")
  }
}

fragment Reviews on Product {
  reviews(first: 10) {
    body
    rating
  }
}

The client gets id, name, and price immediately and can render the page. A second payload carries reviews, and the client merges it into the same result. You can also gate it with a variable, @defer(if: $deferReviews), which is handy when the same fragment serves a server render that wants everything at once.

@stream is the list version. It sends the first initialCount items in the initial payload and streams the rest:

query Feed {
  feed(first: 100) @stream(initialCount: 10) {
    id
    title
  }
}

That pairs well with a resolver that returns an async iterable, since the executor can push each item as soon as it exists.

Wiring it up on the server ​

GraphQL.js 17 shipped stable in June 2026 with @defer and @stream included but deliberately opt-in. The directives are not part of specifiedDirectives, so you add them yourself, and you run operations through a separate executor:

import {
  GraphQLSchema,
  GraphQLDeferDirective,
  GraphQLStreamDirective,
  specifiedDirectives,
  experimentalExecuteIncrementally,
  parse,
} from "graphql";

const schema = new GraphQLSchema({
  query: QueryType,
  // Passing `directives` replaces the defaults, so keep specifiedDirectives
  directives: [
    ...specifiedDirectives,
    GraphQLDeferDirective,
    GraphQLStreamDirective,
  ],
});

const result = await experimentalExecuteIncrementally({
  schema,
  document: parse(source),
  variableValues,
});

if ("initialResult" in result) {
  send(result.initialResult);
  for await (const patch of result.subsequentResults) {
    send(patch);
  }
} else {
  send(result);
}

Two details bite people here. First, forgetting ...specifiedDirectives silently drops @skip, @include, and friends. Second, the plain execute() function rejects schemas that contain these directives, so every code path that executes operations needs to switch.

GraphQL.js produces the payloads but not the wire format. Your server picks the framing, usually HTTP multipart (multipart/mixed), sometimes server-sent events. Apollo Router supports @defer out of the box, so if your graph sits behind it you may already have this plumbing.

The client has to speak the same dialect ​

This is the part to slow down on. Incremental delivery is still a draft in the GraphQL spec (the RFC reached Stage 2 in March 2026 and is still being edited), and the response format has changed more than once along the way. Apollo Client 4 refuses to guess. Out of the box it throws if it sees @defer, and you have to opt into a specific format:

import { ApolloClient, InMemoryCache, HttpLink } from "@apollo/client";
import { Defer20220824Handler } from "@apollo/client/incremental";

const client = new ApolloClient({
  cache: new InMemoryCache(),
  link: new HttpLink({ uri: "/graphql" }),
  incrementalHandler: new Defer20220824Handler(),
});

Defer20220824Handler matches the format Apollo Router ships. There is also a GraphQL17Alpha9Handler for servers built on the newer GraphQL.js format. Pick the one that matches what your server actually sends, then test a real deferred query end to end. A mismatch shows up as data that never merges, not as a helpful error.

In the UI, plan for fields that aren't there yet. In Apollo Client 4, dataState moves from "empty" to "streaming" to "complete", and loading stays true until the last patch lands:

const { data, dataState } = useQuery(PRODUCT_PAGE, { variables: { id } });

if (dataState === "empty") return <Skeleton />;

return (
  <>
    <ProductHeader product={data.product} />
    {data.product.reviews ? (
      <Reviews items={data.product.reviews} />
    ) : (
      <ReviewsSkeleton />
    )}
  </>
);

Reserve space for the deferred section so the late data doesn't shove the page around. Otherwise you trade a slow load for a layout shift.

When not to bother ​

@defer fixes one problem: a fast majority waiting on a slow minority. If everything in the query is slow, deferring just adds payloads. If the slow field is slow because of an N+1 query, fix the resolver with batching first. Deferring a bad resolver hides the cost from the user while your database keeps paying it. Some gateways also don't support it yet, so check every hop between the client and the resolver before you count on it.

If your screens do have that "nine fast fields and one slow one" shape, @defer is worth an afternoon. Start with one below-the-fold section, measure time to first render before and after, and read the GraphQL.js defer and stream guide and the Apollo Client @defer docs before you choose a format.

The catch is that the browser decides whether your page is eligible, and a lot of ordinary code makes it ineligible. Nothing errors. Nothing logs. The back button just feels like a fresh page load, and you never find out why.

How bfcache differs from the HTTP cache ​

The HTTP cache stores responses. bfcache stores the whole live page. When a user navigates away, the browser freezes the document instead of destroying it: pending timers and unresolved promises are paused, and the task queues stop processing. If the user comes back soon, the browser unpauses everything and shows the page as it was.

That's why a bfcache restore beats even a perfectly tuned HTTP-cached load. There's no parsing, no script execution, no hydration. It also means your code needs to cope with a page that "wakes up" rather than loads. The pageshow event is your hook for that, and its persisted property tells you which kind of show it was:

window.addEventListener("pageshow", (event) => {
  if (event.persisted) {
    // Restored from bfcache: the DOM and JS state are exactly as the user left them.
    refreshCartBadge();
    refreshRelativeTimestamps();
  }
});

That snippet also covers the one real downside. A restored page skips revalidation, so Cache-Control: no-cache doesn't apply. If something like a cart count or a signed-in state could be stale, refresh it in pageshow.

The usual blockers ​

Most ineligible pages trip on one of a short list of causes.

unload listeners. This is the big one. Firefox on desktop refuses to cache any page with an unload handler, and Chrome has deprecated the event entirely, so in Chrome your handler mostly won't even run. Use pagehide instead, which fires every time unload would and also when the page enters bfcache:

// Before: blocks bfcache in Firefox, unreliable everywhere
window.addEventListener("unload", flushAnalytics);

// After: works with bfcache in every browser
window.addEventListener("pagehide", flushAnalytics);

The trap is that the unload listener is often not yours. An old analytics snippet or a third-party widget can add one. In Chromium you can forbid it outright with a response header, so nothing on the page can register one:

Permissions-Policy: unload=()

Cache-Control: no-store on the document. Browsers have historically kept no-store pages out of bfcache. Chrome now lets some of them in, with a shorter three-minute timeout and eviction if cookies change, but other browsers still block. Reserve no-store for pages with sensitive data. If you just want fresh content, no-cache or max-age=0 makes the browser revalidate normal loads without costing you bfcache.

Open connections. Some browsers won't cache a page holding an open IndexedDB connection, an in-flight fetch(), or a WebRTC connection, because pausing it could stall other tabs on the same origin. Chrome (as of 149) and Safari no longer block on open WebSockets, but other browsers still do. Close those connections in pagehide and reopen them in pageshow:

let socket;

function connect() {
  socket = new WebSocket("wss://example.com/live");
  socket.addEventListener("message", handleMessage);
}

window.addEventListener("pagehide", () => socket?.close());
window.addEventListener("pageshow", (event) => {
  // Normal loads connect elsewhere; only reconnect on a bfcache restore.
  if (event.persisted) connect();
});

connect();

window.opener references. A page that opened a window it still controls, or that was opened with an opener reference, can't be cached safely. rel="noopener" is the default for target="_blank" links in modern browsers, so this usually only bites apps that use window.open() plus postMessage.

Unconditional beforeunload. It no longer blocks bfcache in modern browsers, but it's still unreliable. Attach it only while there are unsaved changes and remove it once they're saved.

Find out why you're not getting cached ​

Start in DevTools: Application → Back/forward cache → Run test. Chrome navigates away and back, then lists every blocker, and marks the ones you can fix as Actionable. Lighthouse runs the same check as its bfcache audit.

Lab tests only catch what happens on your machine, though. For real users, Chrome (from version 123) exposes notRestoredReasons on the navigation timing entry. It's still marked experimental and is Chromium-only, so treat it as a diagnostic, not a feature:

const [nav] = performance.getEntriesByType("navigation");

if (nav?.type === "back_forward" && nav.notRestoredReasons) {
  const reasons = nav.notRestoredReasons.reasons.map((r) => r.reason);
  sendToAnalytics("bfcache_miss", { url: location.pathname, reasons });
}

One subtlety: notRestoredReasons is null for non-history navigations and undefined where unsupported, and a null value doesn't prove the page was restored. Use pageshow's persisted to count actual hits. Also expect a hit rate below 100% even on a perfect page. Browsers evict cached pages to save memory, and a restarted browser or a duplicated tab never uses bfcache.

One more measurement gotcha: bfcache restores replace some of your fastest page loads, so your field load metrics can look worse after you fix eligibility, even though users are getting faster navigations. Segment your metrics by navigation type, and use the web-vitals library, which already reports bfcache restores as their own visits.

The takeaway ​

bfcache is the rare performance win that's mostly deletion: remove the unload listener, drop no-store where it isn't protecting anything, and close connections on pagehide. Run the DevTools test on your three most-visited pages today, since a single blocker on a high-traffic template is usually the whole story. The web.dev bfcache guide and Chrome's notRestoredReasons docs cover the long tail.

Laravel 13 removes that catch. It ships JsonApiResource, a first-party resource class that extends the JsonResource you already know and produces spec-compliant output. It handles resource objects, relationships, include, sparse fieldsets, links, meta, and the application/vnd.api+json header. Your existing resources keep working, so you can adopt it one endpoint at a time.

From Model to Resource Object ​

Generate one with the new --json-api flag:

php artisan make:resource PostResource --json-api

The generated class gives you two properties instead of a toArray method:

<?php

namespace App\Http\Resources;

use Illuminate\Http\Resources\JsonApi\JsonApiResource;

class PostResource extends JsonApiResource
{
    public $attributes = [
        'title',
        'body',
        'created_at',
    ];

    public $relationships = [
        'author' => UserResource::class,
        'comments',
    ];
}

Return it the same way you return any resource, with new PostResource($post) or $post->toResource(), and the response comes back in the shape the spec requires:

{
  "data": {
    "id": "1",
    "type": "posts",
    "attributes": {
      "title": "Hello World",
      "body": "This is my first post.",
      "created_at": "2026-10-28T14:02:11.000000Z"
    }
  }
}

Look at what you didn't write. The id is cast to a string, which the spec requires and hand-rolled APIs often get wrong. The type comes from the class name, so PostResource becomes posts and BlogPostResource becomes blog_posts. When those defaults are wrong, for example an AuthorResource wrapping a User model or a public UUID instead of the primary key, override toType() and toId():

public function toType(Request $request): string
{
    return 'authors';
}

public function toId(Request $request): string
{
    return (string) $this->uuid;
}

If you need computed values, override toAttributes() instead of using the property. Closures in that array are evaluated lazily, so an expensive attribute only runs when it actually ends up in the response:

public function toAttributes(Request $request): array
{
    return [
        'title' => $this->title,
        'is_published' => fn () => $this->published_at !== null,
        'reading_time' => fn () => $this->calculateReadingTime(),
    ];
}

Includes and Sparse Fieldsets Come Free ​

This is where the class earns its place. Relationships are not serialized by default. They only appear when the client asks for them:

GET /api/posts/1?include=author,comments

The data object then gets a relationships key holding identifier objects ({ "id": "1", "type": "users" }), and the full related records go into a top-level included array, so each one appears once no matter how many posts reference it. Nested paths use dot notation (?include=comments.author). Nesting depth is capped by default, and you can raise or lower the cap with JsonApiResource::maxRelationshipDepth(3) in a service provider.

Sparse fieldsets work the same way. A mobile list view that only needs titles can ask for them, per resource type:

GET /api/posts?fields[posts]=title,created_at&fields[users]=name

You don't write any parsing code for either of these. For an internal endpoint where you want fixed output whatever the query string says, chain ->ignoreFieldsAndIncludesInQueryString() onto the resource.

What It Doesn't Do for You ​

JsonApiResource is a serializer. It shapes the response. It doesn't build your query, and that leaves two gaps you have to close yourself.

First, eager loading. The resource resolves a relationship when the client includes it, but the docs make no promise that it batch-loads that relationship across a collection. On a list endpoint, assume ?include=author can turn into one query per post unless you load it up front. The safe pattern is to eager-load from an allowlist built from the same query parameter:

use App\Models\Post;
use Illuminate\Http\Request;

Route::get('/api/posts', function (Request $request) {
    $allowed = ['author', 'comments', 'comments.author'];

    $includes = array_values(array_intersect(
        explode(',', (string) $request->query('include', '')),
        $allowed,
    ));

    return Post::with($includes)->latest()->limit(20)->get()->toResourceCollection();
});

Turn on Model::preventLazyLoading() in development and the first missed eager load will throw instead of quietly slowing down production.

Second, filtering and sorting. JSON:API reserves filter and sort parameters, but Laravel's resource ignores them. The Laravel docs point to Spatie's Laravel Query Builder for that side. It also gives you allowedIncludes(), which replaces the hand-written allowlist above.

If you also need full spec compliance on writes (validating application/vnd.api+json request bodies, relationship endpoints, error objects), a full framework like Laravel JSON:API still covers more ground. The first-party class only handles reads.

Should You Switch? ​

If your API already has consumers built around your current response shape, don't migrate it just for tidiness. The shape is the contract, and changing it is a breaking change for every client. Where JsonApiResource pays off is a new API, a new version prefix, or a public API where third-party clients will thank you for following a spec they already have tooling for. Start with one endpoint, put Model::preventLazyLoading() in place, and read the JSON:API resources section of the Laravel docs for the toLinks() and toMeta() hooks this post skipped.

The win is real, but it comes with a contract change that is easy to trip over. Once the first byte is on the wire, the HTTP status and headers are locked in. Let's look at both halves.

Turning it on ​

Streaming is experimental and off by default. Enable it in nuxt.config.ts:

export default defineNuxtConfig({
  experimental: {
    ssrStreaming: true,
  },
});

With this on, Nuxt immediately flushes an HTML shell (your <head>, styles, preload hints, and entry scripts) and then streams the body as Vue renders it. The browser can start fetching CSS, fonts, and the JS entry chunk while your server is still waiting on that slow API.

Bots and crawlers are excluded by default, so Googlebot and friends still get a fully buffered response. If you have an internal crawler or a link-preview service that chokes on streamed HTML, you can widen the match:

export default defineNuxtConfig({
  experimental: {
    ssrStreaming: {
      botRegex: /googlebot|bingbot|slackbot|my-internal-crawler/i,
    },
  },
});

Be realistic about what improves. Time to First Byte drops reliably, because the shell no longer waits on your data. Largest Contentful Paint may improve, depending on how much of the route's JavaScript overlaps the entry chunk and whether your LCP element sits behind the slow fetch. A page whose hero is rendered from an awaited API call still has to wait for that call before the hero arrives; you just stop wasting that time on idle network.

The rule: the response is committed at byte one ​

HTTP sends the status line and headers before the body. A buffered renderer can change its mind right up until the end. A streaming renderer cannot. Anything that tries to mutate the response after rendering has begun simply can't reach the client.

That covers more code than you might expect:

<!-- pages/products/[slug].vue -->
<script setup lang="ts">
const route = useRoute();
const { data: product } = await useFetch(`/api/products/${route.params.slug}`);

if (!product.value) {
  // Too late under streaming: a 200 has already been sent
  setResponseStatus(useRequestEvent()!, 404);
}

// Also too late: the Set-Cookie header is already gone
const lastViewed = useCookie("last-viewed");
lastViewed.value = String(route.params.slug);
</script>

The release notes call out setResponseStatus() in <script setup> and cookie writes during middleware as typical cases. Nuxt does not fail silently here: in development it logs a warning naming each dropped mutation. Treat those warnings as bugs, not noise.

Nuxt also handles the common cases for you. Routes with redirect, cache, isr, swr, noScripts, or ssr: false route rules automatically fall back to the buffered renderer, so caching and redirect setups keep working.

Living with it: opt out where the response matters ​

The pragmatic approach is to stream the routes where the response is boring (marketing pages, docs, blog posts, dashboards behind auth) and keep buffering the ones that need to set status codes or cookies based on rendered data. Per-route opt-out uses routeRules:

export default defineNuxtConfig({
  experimental: {
    ssrStreaming: true,
  },
  routeRules: {
    "/products/**": { streaming: false },
    "/checkout/**": { streaming: false },
  },
});

For logic that doesn't depend on rendered output, move it earlier instead of opting out. Nitro server middleware runs before the renderer starts, so headers and cookies set there are still in time:

// server/middleware/visitor-id.ts
export default defineEventHandler((event) => {
  if (!getCookie(event, "visitor-id")) {
    setCookie(event, "visitor-id", crypto.randomUUID(), {
      httpOnly: true,
      sameSite: "lax",
      maxAge: 60 * 60 * 24 * 365,
    });
  }
});

A quick checklist before you flip the flag on a real app:

1. Search for setResponseStatus, setHeader, setResponseHeader, and cookie writes in pages/, layouts/, components/, and route middleware.
2. Run the app in dev with streaming on and click through your key routes, watching for dropped-mutation warnings.
3. Decide per route: move the logic into server middleware, or add streaming: false.
4. Check that 404 pages still return 404 (curl with -I is enough), because a soft 404 is an SEO problem you won't see in the browser.

Where this leaves you ​

SSR streaming is the kind of feature that rewards a careful rollout: turn it on, read the dev warnings, opt out the handful of routes that need control of their response, and measure TTFB and LCP before and after rather than assuming. Because it is still experimental, expect the details to shift as the Nuxt team works toward v5. The Nuxt 4.5 release post and the original pull request are the best places to track the fallback rules and caveats as they evolve.

The usual workarounds are all a little sad. Ask the backend to send IDs as strings (id_str, if you remember the old Twitter API). Pull in a third-party parser like json-bigint. Or run a regex over the raw response to wrap long numbers in quotes before parsing, and hope nothing in a string field looks like a number. The platform now has a real fix: the JSON.parse source text access proposal, which adds a context argument to revivers and a matching JSON.rawJSON() for serialization. It reached Stage 4 at TC39 in late 2025, and it is already Baseline: Chrome 114, Firefox 135, Safari 18.4, Node 21, Deno 1.33, and Bun 1.1.43 all ship it.

The reviver gets a third argument ​

A reviver has always received (key, value). It now receives (key, value, context), and for primitive values context.source is the exact slice of JSON text that produced value. The number was still parsed into a lossy double, but you get the original digits next to it, so you can decide what it should become.

const json = '{"orderId": 9007199254740993, "total": 42.5}';

const order = JSON.parse(json, (key, value, context) => {
  if (key === "orderId") {
    // value is already rounded; context.source is not
    return BigInt(context.source);
  }
  return value;
});

order.orderId; // 9007199254740993n
order.total; // 42.5

Keying off property names works when you control the schema, but a generic version is more useful in a shared fetch helper. Promote only integers that actually lost precision, and leave everything else alone:

const INTEGER = /^-?\d+$/;

export function preciseReviver(key, value, context) {
  if (
    typeof value === "number" &&
    !Number.isSafeInteger(value) &&
    context?.source &&
    INTEGER.test(context.source)
  ) {
    return BigInt(context.source);
  }
  return value;
}

const res = await fetch("/api/orders");
const data = JSON.parse(await res.text(), preciseReviver);

Two details there matter. Response.json() doesn't accept a reviver, so you read the body as text and parse it yourself. And the optional chaining on context?.source is deliberate: context.source only exists for primitives. When the reviver is called for an object or array, source is absent, because there's no single meaningful slice of text to give you once the children have already been revived.

Writing it back out with JSON.rawJSON ​

Parsing is half the problem. Hand that BigInt to JSON.stringify and you get TypeError: Do not know how to serialize a BigInt. Convert it to a Number first and you're back to rounding. JSON.rawJSON() closes the loop: it wraps a piece of JSON text that stringify will emit verbatim.

function preciseReplacer(key, value) {
  return typeof value === "bigint" ? JSON.rawJSON(value.toString()) : value;
}

JSON.stringify({ orderId: 9007199254740993n }, preciseReplacer);
// '{"orderId":9007199254740993}'

The output is a real JSON number, not a quoted string, so a Go or Java backend expecting an int64 reads it without any schema change. JSON.rawJSON is strict about what it accepts: the text must be valid JSON for a primitive, so JSON.rawJSON('[1, 2]') or a string containing a raw line break throws a SyntaxError. The returned object is frozen with a null prototype, and JSON.isRawJSON() tells you if you're holding one.

Decimals, not just big integers ​

Money is the other place this pays off. 0.1 parsed as a double is not exactly one tenth, and a payments API that returns "amount": 19.99 hands you a value that's already slightly wrong before your decimal library sees it. With context.source you can feed the original digits straight into whatever arbitrary-precision type you use:

import Decimal from "decimal.js";

const invoice = JSON.parse(body, (key, value, context) =>
  key === "amount" ? new Decimal(context.source) : value,
);

On the way out, JSON.rawJSON(amount.toFixed(2)) writes 19.99 as an unquoted number again.

When not to reach for it ​

A reviver runs once per value in the document, so it is measurably slower than a plain JSON.parse on large payloads. If your IDs are already strings, or every number fits in the safe range, you don't need any of this. In TypeScript, older lib definitions may not know about the third reviver argument or JSON.rawJSON yet, so you might need a small ambient declaration until your lib setting catches up. For older browsers, core-js ships a polyfill for both halves.

The bigger change is where the fix lives. Precision used to be something you negotiated with the backend team or patched with a dependency. Now it's a few lines in the one fetch helper every request already goes through. MDN's pages on JSON.parse() and JSON.rawJSON() have the full reference, and the TC39 proposal covers the design reasoning.

That arrangement got less comfortable this year. TypeScript 6.0 deprecated baseUrl, and the TypeScript 7 native compiler drops it entirely. Meanwhile the platform quietly fixed the thing that kept people from using the standard alternative. Node's package.json imports field now accepts a bare #/ prefix, and TypeScript 6.0 understands it. You can have one alias, defined once, that every tool in the chain reads from the same place.

What actually changed ​

Subpath imports have existed in Node since v14. The imports field in package.json lets a package define private specifiers that only resolve from inside that package. The rule is that every key must start with #, so nothing can collide with a real package name on npm.

The catch was that #/ on its own was not a valid key. You had to write #src/* or #lib/* or #root/*, which always felt like inventing a name to satisfy a parser. People coming from bundlers wanted the @/ feel, tried #/, got a resolution error, and went back to paths.

Node fixed that in v25.4.0 and backported it to v24.14.0, per the version history in the Node.js packages docs. TypeScript 6.0 added matching support under moduleResolution set to nodenext or bundler. So this is now legal:

{
  "name": "my-app",
  "type": "module",
  "imports": {
    "#/*": "./src/*"
  }
}

import { formatPrice } from "#/utils/format.js";
import { useCart } from "#/composables/useCart.js";

The * is plain string replacement, so #/utils/format.js becomes ./src/utils/format.js, nested folders included. TypeScript applies its usual .js to .ts lookup on the result, the same way it does for relative imports.

Migrating a Vite app off paths ​

For a typical Vue or React project built with Vite, the move is mostly deletion. Add the imports field above, then strip the duplicates:

 // tsconfig.json
 {
   "compilerOptions": {
     "moduleResolution": "bundler",
-    "baseUrl": ".",
-    "paths": {
-      "@/*": ["./src/*"]
-    }
   }
 }

 // vite.config.ts
 export default defineConfig({
   plugins: [vue()],
-  resolve: {
-    alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) },
-  },
 })

A current Vite release resolves the imports field natively, and Vitest inherits Vite's resolver, so the test config needs nothing extra. SvelteKit is already heading this way: the docs for its next version scaffold a #lib entry in package.json instead of the old built-in $lib alias.

Then rewrite the specifiers. Because the shape is identical, a find-and-replace from '@/ to '#/ covers most of a codebase. Run tsc --noEmit and your test suite afterward, since that will catch any file that relied on extensionless imports your bundler was forgiving about.

Node services and the dist question ​

The bigger win is code that Node runs directly. A paths alias in a Node service was always a trap: tsc happily type-checks @/db/client, emits it unchanged into dist, and the first run crashes with ERR_MODULE_NOT_FOUND. The usual fix was another tool, like tsc-alias or tsconfig-paths, to rewrite or patch resolution after the fact.

With subpath imports, Node itself is the resolver. Point the alias at your build output:

{
  "type": "module",
  "imports": {
    "#/*": "./dist/*"
  }
}

That is the exact example in the TypeScript 6.0 announcement. With rootDir and outDir set explicitly, TypeScript maps the dist path back to the matching source file in src for type-checking, while Node resolves the emitted JavaScript at runtime. No post-build rewrite step.

If you run TypeScript directly with Node's type stripping and never build, map to source instead and write your imports with the real .ts extension. Either way, the alias lives in one file that Node reads.

The tradeoffs ​

A few things to know before you commit to it:

• Version floor. #/ needs Node 24.14+ or 25.4+. On Node 22, or anything older, you still need a named prefix like #src/*. Pin engines in package.json so nobody discovers this in CI.
• Tooling lag. Every resolver has to implement the #/ rule. The oxc resolver needed an explicit change for it, and older Jest, ESLint import plugins, or editor extensions may not have caught up. Check yours before a big rename.
• Private by design. imports only applies inside the package that declares it. In a monorepo, each workspace package gets its own aliases. It will not let apps/web reach into packages/ui/src, and that's a feature.
• It's #, not @. Some teams will find this ugly for a week. Then it's just the alias.

If your tsconfig still has baseUrl and a paths block, you have to touch it before TypeScript 7 anyway. That's the moment to move the alias somewhere Node, Vite, Vitest, and TypeScript all agree on. Start with the Node.js subpath imports docs, add one line to package.json, and delete three config blocks.

The other version of this problem is worse. You want to observe or focus a component from a library, and that component doesn't forward its ref. Now you're either forking the library or adding the wrapper div anyway.

React 19.3, released on September 9, 2026, made Fragment refs stable. You can now pass a ref to <Fragment> and get back a FragmentInstance, an object with a small set of DOM methods that operate on the fragment's children as a group. No wrapper, no changes to the children.

What a FragmentInstance can do ​

The setup is the ref you already know, just on a Fragment. One catch: the <>...</> shorthand can't take props, so you need the explicit Fragment import.

import { Fragment, useRef } from "react";

function Toolbar({ children }) {
  const groupRef = useRef(null);
  return <Fragment ref={groupRef}>{children}</Fragment>;
}

groupRef.current is now a FragmentInstance. Its methods fall into four groups:

• Events: addEventListener, removeEventListener, and dispatchEvent
• Focus: focus, focusLast, and blur
• Observers: observeUsing and unobserveUsing, which take an IntersectionObserver or ResizeObserver
• Layout: getClientRects, getRootNode, compareDocumentPosition, and scrollIntoView

The important detail is which nodes these touch. Event, observer, and layout methods target the fragment's first-level DOM children. React looks through component boundaries to find them, so if a child component renders a <section>, that <section> is a target. But it stops at the first real DOM node: an element nested inside that <section> is not. Focus methods are the exception. focus() and focusLast() search depth-first through everything, which is what you want when the inputs are buried inside a <fieldset> and a <label>.

Listeners are also kept in sync. If children are added or removed later, the FragmentInstance attaches or detaches the listener for you.

Observing visibility with no wrapper and no forwarded refs ​

This is the case that used to force the wrapper div. Here is a reusable InView component that reports whether any of its children are on screen:

import { Fragment, useLayoutEffect, useRef } from "react";

export function InView({ onChange, children }) {
  const fragmentRef = useRef(null);

  useLayoutEffect(() => {
    const visible = new Set();
    const observer = new IntersectionObserver((entries) => {
      for (const entry of entries) {
        if (entry.isIntersecting) visible.add(entry.target);
        else visible.delete(entry.target);
      }
      onChange(visible.size > 0);
    });

    const fragment = fragmentRef.current;
    fragment.observeUsing(observer);
    return () => fragment.unobserveUsing(observer);
  }, [onChange]);

  return <Fragment ref={fragmentRef}>{children}</Fragment>;
}

Use it around anything, including third-party components that never heard of refs:

<InView onChange={setHeroVisible}>
  <VendorBanner />
  <PricingTable />
</InView>

VendorBanner and PricingTable render exactly the DOM they always did. Your CSS grid still sees two items, not one wrapper. If onChange is an inline function, wrap it in useCallback (or let the React Compiler handle it) so the observer isn't torn down on every render.

One warning from the docs: observeUsing doesn't work on text nodes, and React logs a dev warning if a fragment contains only text.

Focus management for groups ​

Focus is the other place this pays off, and it's an accessibility win. When a disclosure panel opens, a dialog-like section mounts, or a validation error appears, you usually want to move focus into it. Before, that meant a ref on the specific input, which meant threading refs through whatever components sat in between.

import { Fragment, useEffect, useRef } from "react";

function StepPanel({ isActive, children }) {
  const stepRef = useRef(null);

  useEffect(() => {
    if (isActive) stepRef.current.focus({ preventScroll: true });
  }, [isActive]);

  return <Fragment ref={stepRef}>{children}</Fragment>;
}

focus() finds the first focusable element anywhere inside the children, and focusLast() finds the last one. That pair is most of what you need for a simple focus loop at the edges of a section. blur() only does something if the active element is actually inside the fragment, so it's safe to call without checking first.

Two small gotchas. scrollIntoView takes only a boolean (true aligns the first child to the top, false aligns the last child to the bottom), and passing a ScrollIntoViewOptions object throws. And listeners added through addEventListener are not applied to children inside a hidden <Activity> boundary until it becomes visible again.

When to reach for it ​

Fragment refs aren't a replacement for regular refs. If you own the element and it's a single node, a plain ref on that element is still simpler. Reach for a Fragment ref when you need to attach behavior to a group of siblings, or to components you don't control, and a wrapper element would cost you layout, semantics, or both.

If you're already on React 19.3, try deleting one wrapper div this week. The <Fragment> reference covers every method, and the React 19.3 release post walks through View Transitions and the new browser() API that shipped alongside it.

The gap property has handled spacing in grid and flexbox for years, but the space itself was never stylable. As of Chrome and Edge 149, it is. CSS gap decorations take the column-rule property you may remember from multi-column layout, make it work in grid and flexbox, and add a row-rule partner for the other axis.

The basics: column-rule, row-rule, and rule ​

If you've used border, you already know the syntax. Each rule takes a width, a style, and a color:

.cards {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(16rem, 1fr));
  gap: 2rem;
  column-rule: 1px solid #d4d4d8;
  row-rule: 1px solid #d4d4d8;
}

When both axes use the same value, the rule shorthand sets them together:

.cards {
  rule: 1px solid #d4d4d8;
}

The lines are drawn in the middle of each gap and follow the layout wherever it goes. Change the column count, let auto-fill reflow the grid at a narrower viewport, or add a tenth card, and the decorations move with it. There are no selectors that assume a fixed row length, and nothing gets added to the DOM or the accessibility tree. Decorations are purely visual and don't change layout, so turning them on never shifts anything.

Flexbox works the same way. A wrapping nav with dashed separators is one declaration:

nav ul {
  display: flex;
  flex-wrap: wrap;
  gap: 1.5rem;
  column-rule: 2px dashed #71717a;
}

Patterns and per-gap styles ​

Rules accept comma-separated lists that cycle across gaps, plus a repeat() syntax borrowed from grid tracks. That makes alternating styles trivial. Here's a calendar where hour boundaries are solid and half-hours are dashed:

.calendar {
  display: grid;
  row-gap: 0.5rem;
  row-rule-width: 2px, 1px;
  row-rule-style: solid, dashed;
  row-rule-color: #e4e4e7, #f4f4f5;
}

And a page-level grid where the first divider is heavy and every one after it is thin, however many sections you add:

body {
  display: grid;
  gap: 4rem;
  row-rule:
    0.5rem solid #e4e4e7,
    repeat(auto, 2px solid #e4e4e7);
}

repeat(auto, ...) is the important bit. It fills however many gaps remain, so the rule list never needs updating when content grows.

Fine-tuning: insets, breaks, and empty cells ​

The defaults look reasonable, but the real win is the control layer on top. A few properties carry most of the weight.

Insets shrink lines away from their ends. column-rule-inset: 1rem pulls each vertical line in from the top and bottom, which is the "separator that doesn't touch the edges" look from a media card. For more precision, rule-inset-cap targets the outer ends of a line and rule-inset-junction targets the points where row and column gaps meet. The overlap-join keyword joins rules neatly at intersections while keeping the outer ends flush.

Breaks decide what happens at intersections. rule-break: intersection cuts lines where gaps cross, giving you separate segments per cell. rule-break: none draws continuous lines straight through.

Visibility solves the dangling-line problem. A grid whose last row is only partly filled would otherwise draw rules next to empty cells. rule-visibility-items: between only paints a rule when there are items on both sides, and around paints it when at least one side has an item.

Overlap sets which axis wins where they cross. With a thick column rule and a thin row rule, rule-overlap: column-over-row puts the vertical lines on top.

Put together, a dashboard grid with clean joins and no stray lines looks like this:

.dashboard {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 1.5rem;
  rule: 1px solid #3f3f46;
  rule-inset-cap: 0;
  rule-inset-junction: 0.5rem;
  rule-visibility-items: between;
  transition: rule-inset-junction 0.3s;
}

.dashboard:hover {
  rule-inset-junction: 0;
}

Yes, that transition works. Rule width, color, and insets are all animatable.

Shipping it today ​

This is a Chromium feature right now: Chrome and Edge 149 and other browsers built on the same engine. Firefox and Safari haven't shipped it yet, so it isn't Baseline. A polyfill is in development from Microsoft, but most uses don't need one. In a browser without support, the gaps simply render as plain space, which is usually a perfectly good fallback for a decorative line.

If a missing divider would actually hurt readability, gate a fallback with @supports:

.cards > * {
  border-bottom: 1px solid #d4d4d8;
}

@supports (row-rule: 1px solid) {
  .cards > * {
    border-bottom: none;
  }

  .cards {
    rule: 1px solid #d4d4d8;
    rule-visibility-items: between;
  }
}

One heads-up if you tried the developer trial back in Chrome 139: some names changed before release. column-rule-outset became column-rule-inset, the paint-order property is now rule-overlap, and the visibility properties are new. Old demos and blog posts may use the earlier names.

Treat gap decorations as progressive enhancement and start deleting those :nth-child border rules on the next layout you touch. The Chrome stable announcement covers every property, and Microsoft's interactive playground is the fastest way to get a feel for insets and breaks before you write any CSS of your own.

Svelte 5 has had a fix for this since 5.3: <svelte:boundary>. It has quietly grown into one of the more useful special elements in the framework, and as of 5.51 it can even handle errors during server-side rendering. If you haven't reached for it yet, here's what it does and where it fits.

Walling Off a Component ​

A boundary wraps part of your tree. If anything inside throws while rendering or while running an effect, the boundary catches it, removes the broken content, and renders a failed snippet in its place. The snippet receives the error and a reset function that rebuilds the contents from scratch.

<script>
  import RevenueChart from './RevenueChart.svelte';
</script>

<svelte:boundary>
  <RevenueChart />

  {#snippet failed(error, reset)}
    <div class="card card--error">
      <p>The revenue chart couldn't load.</p>
      <button onclick={reset}>Try again</button>
    </div>
  {/snippet}
</svelte:boundary>

The rest of the page keeps rendering normally. Only the chart's slot shows the fallback, and reset gives the user a way to retry without a full reload.

If you'd rather report the error than (or as well as) render something, pass an onerror handler. It gets the same error and reset arguments:

<script>
  import * as Sentry from '@sentry/svelte';
  import ActivityFeed from './ActivityFeed.svelte';
</script>

<svelte:boundary onerror={(error) => Sentry.captureException(error)}>
  <ActivityFeed />

  {#snippet failed()}
    <p>Activity is unavailable right now.</p>
  {/snippet}
</svelte:boundary>

If onerror itself throws, or you rethrow, the error bubbles to the nearest parent boundary. That lets you build layers: a tight boundary around each risky widget, and a coarse one near the root as the last line of defense.

What Boundaries Don't Catch ​

This is the part that trips people up. Boundaries catch errors that happen during rendering and inside effects. They do not catch errors in event handlers, inside a setTimeout, or in other async work that runs outside the render cycle.

<svelte:boundary>
  <!-- This throw is NOT caught by the boundary -->
  <button onclick={() => { throw new Error('nope'); }}>Click</button>

  {#snippet failed()}<p>Never shown for the click error</p>{/snippet}
</svelte:boundary>

That's the same split React draws, and for the same reason: an event handler failing doesn't leave the UI in a half-rendered state, so there's nothing for a boundary to replace. Handle those errors where they happen, with try/catch and some local state.

Pending UI for await ​

Boundaries also handle the other side of async rendering. With Svelte's await expressions, you can put an await directly in your markup, and a boundary's pending snippet shows while those expressions first resolve:

<script>
  let { userId } = $props();
</script>

<svelte:boundary>
  <h2>{(await getUser(userId)).name}</h2>
  <p>{(await getStats(userId)).posts} posts</p>

  {#snippet pending()}
    <div class="skeleton" aria-busy="true"></div>
  {/snippet}

  {#snippet failed(error, reset)}
    <button onclick={reset}>Couldn't load profile. Retry?</button>
  {/snippet}
</svelte:boundary>

Two caveats. First, pending only shows on the initial load. Later updates keep the old content on screen, and you use $effect.pending() if you want a spinner for those. Second, during server-side rendering, a boundary with a pending snippet renders only that snippet and skips its content, so put boundaries around the slow, non-critical parts of the page and not around the content you need indexed.

Boundaries on the Server ​

Until recently, boundaries did nothing during SSR. An error in any component failed the whole render() call. Svelte 5.51 changed that with a transformError option on render from svelte/server:

import { render } from "svelte/server";
import App from "./App.svelte";

const { head, body } = await render(App, {
  transformError: (error) => {
    // Log the real error, with its stack, on the server...
    console.error(error);
    // ...and send only a safe, serializable shape to the browser
    return { message: "Something went wrong loading this section." };
  },
});

When a component inside a boundary with a failed snippet throws during SSR, transformError decides what the snippet receives. The return value has to be JSON-serializable because it gets serialized into the page and used to hydrate the failed snippet in the browser. If the boundary also has onerror, it fires on hydration with that deserialized object. If transformError throws, the whole render fails as before.

The redaction step matters. Server errors can carry database messages, file paths, and stack traces, and the Svelte docs explicitly recommend sanitizing them rather than shipping them to the client.

If you're on SvelteKit, you don't call render yourself, so the framework has to wire transformError up for you. The Svelte docs say that support is coming via SvelteKit's handleError hook. Check the SvelteKit changelog for your version before you count on server-side boundaries working there. Until then, handleError and +error.svelte remain the SvelteKit way to deal with errors in load and on the server.

Where to Put Them ​

A good rule: wrap anything whose failure shouldn't cost the user the rest of the page. Third-party embeds, data visualizations, user-generated content renderers, and any widget fed by a flaky API are all prime candidates. Keep boundaries out of trivial components, because a fallback for every button is noise. Start with one root-level boundary plus a few around your riskiest widgets, wire onerror into whatever error tracking you already use, and read the <svelte:boundary> docs for the full API.

A dependency cooldown attacks that window directly. Instead of installing whatever was published thirty seconds ago, your package manager only accepts versions that have existed for a while. It's a boring idea, and that's why it works: you let the rest of the ecosystem be the canary. Every major package manager now supports it, but each one picked its own config key and, annoyingly, its own unit of time.

One idea, four spellings ​

Here's the same "wait at least a day" policy in each tool.

pnpm uses minutes, configured in pnpm-workspace.yaml. Since pnpm 11 this is on by default at 1440 minutes, so if you're on a current pnpm you already have it:

# pnpm-workspace.yaml
minimumReleaseAge: 1440 # minutes
minimumReleaseAgeExclude:
  - "@myorg/*"

npm added min-release-age in CLI 11.10, measured in days and off by default:

# .npmrc
min-release-age=1

Bun uses seconds, under the [install] table:

# bunfig.toml
[install]
minimumReleaseAge = 86400 # seconds
minimumReleaseAgeExcludes = ["@types/node", "typescript"]

Yarn Berry (4.10+) calls it npmMinimalAgeGate, in minutes:

# .yarnrc.yml
npmMinimalAgeGate: 1440

Minutes, days, seconds, minutes. If you maintain a repo that switches package managers, or you copy a snippet from a blog post written for a different tool, it's very easy to set a 1440-day cooldown in npm or a 24-second one in Bun. Leave a comment with the unit next to the number every time.

The details that actually matter ​

The headline setting is simple. The edge cases are where teams get surprised.

It applies to transitive dependencies too. That's the point: the attack rarely lands in a package you depend on directly. pnpm's docs are explicit that the gate covers the whole tree, which also means a deep dependency like caniuse-lite (which publishes constantly) can be the thing that trips it.

Strict vs. fallback. In pnpm, if nothing in your requested range is old enough, there are two possible behaviors: fail, or fall back to the too-new version. pnpm's built-in default of 1440 is non-strict for backward compatibility, so it quietly falls back. The moment you set minimumReleaseAge yourself, minimumReleaseAgeStrict flips to true and the install fails instead. That's the behavior you want for security, but be ready for it.

Lockfiles behave differently per tool. Bun only applies the gate during new resolution, so entries already in bun.lock are left alone. pnpm goes further: by default it re-checks every lockfile entry against the policy on install, which catches a lockfile someone generated under a weaker setting. You can turn that off with trustLockfile: true, but only do it if every commit comes from people you trust.

Missing timestamps pass by default. The gate relies on the registry's time metadata. Some private registries and mirrors don't serve it, and both pnpm and Bun treat an undated version as passing. If you run an internal proxy, pnpm lets you tighten this:

minimumReleaseAgeIgnoreMissingTime: false

npm's config output can lie to you. There's an open npm CLI issue where npm config ls --long reports min-release-age = null even though npm install is honoring the setting, because npm converts it to a --before date internally. Test the behavior with an install, not by reading the config dump.

Where it bites, and how to live with it ​

The most common complaint after pnpm 11 shipped wasn't about attacks. It was Dependabot. A bot opens a PR the moment a new version appears, CI runs a frozen install, and the brand-new version is younger than the cooldown, so CI goes red. The PR isn't wrong, it's just early. Your options are to delay the bot (Dependabot and Renovate both support a minimum age or cooldown on their side), or add a narrow, version-pinned exclusion:

minimumReleaseAgeExclude:
  - nx@21.6.5
  - webpack@4.47.0 || 5.102.1

Pinning to a specific version beats excluding a whole package name. A name-level exclusion means every future release of that package skips the gate, which is exactly the hole an attacker wants. pnpm can even clean up stale exclusions for you with minimumReleaseAgeExcludePrune: true.

The other real cost is urgent security patches. When a CVE fix lands and you need it now, the cooldown is in your way. npm lets you override per command:

npm i --min-release-age 0 some-package@1.4.2

Use that deliberately, for the one package, and don't bake it into scripts.

Finally, be honest about what this protects you from. A cooldown only helps against compromises that get caught quickly. A patient attacker who ships something that sits undetected for weeks walks right through it. It's one layer, alongside lockfiles, allowBuilds / install-script controls, and provenance checks like pnpm's trustPolicy: no-downgrade.

If you're on pnpm 11 or newer, you've already got a soft version of this. Set minimumReleaseAge explicitly so it becomes strict, add a cooldown to your update bot so it stops racing your own policy, and if you're on npm, add min-release-age=1 to your .npmrc today. It's one line, and it turns "we installed the bad version" into "we read about the bad version."

Container size queries solved half of this in 2023: components could finally react to the space they're given instead of the viewport. The other half, reacting to the context they're placed in, became Baseline Newly available in May 2026 when Firefox 151 shipped support for container style queries. Chrome and Edge have had them since 111, and Safari since 18, so this is ready for production with a sensible fallback.

How Style Queries Work ​

A style query asks a question about the computed value of a custom property on an ancestor. If the answer is yes, the nested rules apply to descendants:

.panel {
  --theme: dark;
}

@container style(--theme: dark) {
  .card {
    background: oklch(0.22 0.02 260);
    color: oklch(0.95 0 0);
  }

  .button {
    border-color: currentColor;
  }
}

Two things are different from size queries. First, you don't need container-type. Every element is a style container by default, so @container style(...) checks the nearest ancestor with no setup at all. Second, only custom properties work today. The spec allows style(font-weight: bold) on regular properties, but no browser implements that yet, so stick to --anything.

If you have nested contexts (a light card inside a dark panel inside a light page), name the level you care about:

.site-footer {
  container-name: footer;
  --theme: dark;
}

@container footer style(--theme: dark) {
  .newsletter-form input {
    background: transparent;
    color: inherit;
  }
}

Without a name, the query targets the nearest ancestor. With one, it targets the nearest ancestor with that container-name, which is what you want when themes nest.

The Gotcha: You Can't Query Yourself ​

This is the mistake almost everyone makes on day one:

/* Does not work the way you'd expect */
.card[data-variant="featured"] {
  --variant: featured;
}

@container style(--variant: featured) {
  .card {
    border: 2px solid gold;
  }
}

The query is evaluated against the card's ancestor, not the card. The card's parent never set --variant, so the query fails. Custom properties inherit downward, not upward. The fix is to style a child of the element that holds the value, which in practice means having a wrapper:

<article class="card" style="--variant: featured">
  <div class="card__inner">
    <h3>Pro plan</h3>
    <a class="button" href="/signup">Start trial</a>
  </div>
</article>

@container style(--variant: featured) {
  .card__inner {
    border: 2px solid gold;
  }

  .button {
    background: gold;
    color: black;
  }
}

If you only need a single property on the element itself to change, that's what the if() function is for. A useful rule of thumb: if() produces a conditional value for one element, while a style query sets context for a whole subtree.

It's also worth registering the property with @property. A registered property has a known type and an initial value, so a container that never sets --variant resolves to something predictable instead of the guaranteed-invalid value:

@property --variant {
  syntax: "<custom-ident>";
  initial-value: default;
  inherits: true;
}

Range Queries and a Fallback Plan ​

Exact matching covers themes and variants, but numbers are where it gets interesting. Chrome 142 added range syntax, so you can compare values instead of matching strings:

.meter {
  --fill: 72%;
}

@container style(--fill > 90%) {
  .meter__bar {
    background: oklch(0.6 0.2 25);
  }
}

@container style(--fill > 50%) and style(--fill <= 90%) {
  .meter__bar {
    background: oklch(0.75 0.15 85);
  }
}

Both sides of a comparison must resolve to the same numeric type (length, number, percentage, angle, time, frequency, or resolution). Note the split here: plain equality style queries are Baseline, but range syntax is Chromium-only for now. Treat range queries as a progressive enhancement.

The fallback story is simple because style queries are additive. Write your default component styles outside any query, then layer the contextual variants inside @container style() blocks. A browser that doesn't understand the at-rule skips it entirely and renders the default card. Nothing breaks; the footer card is just light instead of dark. If that's not acceptable for a given component, keep the old modifier class as a fallback alongside the style query and delete it once your analytics say the stragglers are gone.

Where to Start ​

Pick the one place in your codebase where a theme or variant class gets passed down through props or descendant selectors, and replace it with a single custom property on the wrapper and a style query for the children. You'll likely find that the components inside stop needing to know anything about where they live. The MDN guide to container size and style queries covers the full syntax, and Una Kravets' range style queries write-up is worth bookmarking for when the range syntax lands everywhere.

const byAuthor = new Map();

for (const post of posts) {
  if (!byAuthor.has(post.author)) {
    byAuthor.set(post.author, []);
  }
  byAuthor.get(post.author).push(post);
}

It works. It's also three hash lookups for one logical operation, and in TypeScript the get() call still returns T | undefined, so you end up sprinkling a non-null assertion on a value you just guaranteed exists. The upsert proposal fixes this with two small methods, and as of 2026 they ship in every major browser engine.

getOrInsert and getOrInsertComputed ​

The proposal reached Stage 4 at TC39 in January 2026 and adds two methods to both Map and WeakMap:

• map.getOrInsert(key, defaultValue) returns the existing value for key. If there isn't one, it stores defaultValue and returns that.
• map.getOrInsertComputed(key, callback) does the same thing, but only calls callback(key) to build the default when the key is actually missing.

The grouping loop above collapses to one line per item:

const byAuthor = new Map();

for (const post of posts) {
  byAuthor.getOrInsert(post.author, []).push(post);
}

Counting works the same way. Because the method returns the stored value, you can read and write in one expression:

const wordCounts = new Map();

for (const word of text.toLowerCase().match(/\w+/g) ?? []) {
  wordCounts.set(word, wordCounts.getOrInsert(word, 0) + 1);
}

For simple grouping you could also reach for Map.groupBy(), which landed in 2024. The difference is that groupBy builds a new map in one shot from an iterable, while getOrInsert works on a map you're mutating over time: an event stream, a cache, or a registry that's filled lazily as requests come in.

When to use the Computed variant ​

The catch with getOrInsert is that its default is an ordinary argument, so it's evaluated every time, even when the key already exists. Passing [] or 0 costs essentially nothing. Passing new Set() allocates on every call. Passing await fetchConfig(id) or expensiveParse(source) is a real bug.

MDN's own example shows it plainly: calling map.getOrInsert("bar", defaultCreator("bar")) runs defaultCreator even though "bar" is already in the map, while getOrInsertComputed("bar", defaultCreator) doesn't run it at all.

So the rule of thumb is simple: use getOrInsert for cheap literals, and getOrInsertComputed whenever building the default allocates or does work. A memoization helper is the classic case:

const cache = new Map();

function getHighlighter(language) {
  return cache.getOrInsertComputed(language, (lang) =>
    createHighlighter({ lang, theme: "github-dark" }),
  );
}

The callback receives the key, so you can pass a named function instead of an inline closure. It must be callable: anything else throws a TypeError.

WeakMap is where it really shines ​

The same two methods exist on WeakMap, which makes per-object side data much cleaner. Say you need to attach state to DOM elements without putting properties on the nodes themselves:

const elementState = new WeakMap();

function stateFor(el) {
  return elementState.getOrInsertComputed(el, () => ({
    clicks: 0,
    lastSeen: performance.now(),
  }));
}

document.addEventListener("click", (event) => {
  const state = stateFor(event.target);
  state.clicks += 1;
});

When the element is removed and garbage collected, its entry goes with it. No cleanup code, no leaks, and no "is this initialized yet" branch anywhere in your handlers.

Can you ship it today? ​

Support is recent but broad. According to caniuse, getOrInsertComputed is available in Chrome and Edge 145+, Firefox 144+, and Safari 26.2+ on both macOS and iOS, and MDN marks it Baseline 2026 (newly available). That still leaves a tail of users on older Safari and Samsung Internet, so for public sites you'll want a fallback for now. Both core-js and es-shims provide polyfills, and the hand-rolled version is tiny if you'd rather avoid a dependency:

if (!Map.prototype.getOrInsertComputed) {
  Map.prototype.getOrInsertComputed = function (key, callback) {
    if (typeof callback !== "function")
      throw new TypeError("callback must be callable");
    if (this.has(key)) return this.get(key);
    const value = callback(key);
    this.set(key, value);
    return value;
  };
}

For server code, check your runtime before relying on it: node -p "typeof Map.prototype.getOrInsert" prints function when it's there. If your TypeScript lib setting doesn't know about the methods yet, a small declaration file bridges the gap:

interface Map<K, V> {
  getOrInsert(key: K, defaultValue: V): V;
  getOrInsertComputed(key: K, callback: (key: K) => V): V;
}

Note that both return V, not V | undefined, which is the other quiet win here: the non-null assertions go away along with the boilerplate.

The upsert methods aren't flashy, but they're the kind of feature you end up using every day once you know it exists. Next time you type if (!map.has(key)), stop and reach for getOrInsert instead. The MDN reference for getOrInsertComputed is a good place to start.

Astro's answer is live content collections. They shipped as stable in Astro 6 and picked up first-class caching in Astro 7. The pitch is simple: keep the content collection API you already know, but fetch the data when the page is requested instead of when the site is built. No rebuild, no webhook, and the same typed entry.data you get from build-time collections.

Build-time vs. live: two configs, one mental model ​

Build-time collections live in src/content.config.ts, run their loaders during astro build, and persist the results in Astro's data store. That is still the right default. It is fast, works with MDX, and lets Astro optimize images.

Live collections live in a separate file, src/live.config.ts, and use defineLiveCollection(). They require an adapter for on-demand rendering, because the whole point is that the data is fetched per request. There are no built-in live loaders, so you write one or install a community loader.

A live loader is an object with a name and two methods: loadCollection() for lists and loadEntry() for a single item. Each returns data or an Error, never throws.

// src/loaders/changelog.ts
import type { LiveLoader } from "astro/loaders";

interface Release {
  id: string;
  title: string;
  html: string;
  updatedAt: string;
}

export function changelogLoader(opts: {
  apiUrl: string;
  token: string;
}): LiveLoader<Release, { id: string }, { tag?: string }> {
  const headers = { Authorization: `Bearer ${opts.token}` };

  return {
    name: "changelog-loader",
    loadCollection: async ({ filter }) => {
      try {
        const qs = filter?.tag ? `?tag=${encodeURIComponent(filter.tag)}` : "";
        const res = await fetch(`${opts.apiUrl}/releases${qs}`, { headers });
        const releases: Release[] = await res.json();
        return {
          entries: releases.map((r) => ({ id: r.id, data: r })),
          cacheHint: { tags: ["releases"] },
        };
      } catch (error) {
        return {
          error: new Error("Failed to load releases", { cause: error }),
        };
      }
    },
    loadEntry: async ({ filter }) => {
      try {
        const res = await fetch(`${opts.apiUrl}/releases/${filter.id}`, {
          headers,
        });
        if (res.status === 404)
          return { error: new Error("Release not found") };
        const r: Release = await res.json();
        return {
          id: r.id,
          data: r,
          rendered: { html: r.html },
          cacheHint: {
            tags: [`release-${r.id}`],
            lastModified: new Date(r.updatedAt),
          },
        };
      } catch (error) {
        return { error: new Error("Failed to load release", { cause: error }) };
      }
    },
  };
}

Then register it. The Zod schema is optional, but if you provide one it wins over the loader's generic types and validation errors come back as a typed error instead of a crash:

// src/live.config.ts
import { defineLiveCollection } from "astro:content";
import { z } from "astro/zod";
import { changelogLoader } from "./loaders/changelog";

const releases = defineLiveCollection({
  loader: changelogLoader({
    apiUrl: import.meta.env.CMS_URL,
    token: import.meta.env.CMS_TOKEN,
  }),
  schema: z.object({
    id: z.string(),
    title: z.string(),
    html: z.string(),
    updatedAt: z.coerce.date(),
  }),
});

export const collections = { releases };

Querying live data with explicit errors ​

On the page side you swap getEntry() for getLiveEntry() and getCollection() for getLiveCollection(). The difference that matters is the return shape: you get { entry, error } back rather than an exception, which forces you to decide what a CMS outage looks like for your users.

---
// src/pages/changelog/[id].astro
export const prerender = false;
import { getLiveEntry, render } from 'astro:content';
import { LiveEntryNotFoundError } from 'astro/content/runtime';

const { entry, error } = await getLiveEntry('releases', Astro.params.id);

if (error) {
  if (error instanceof LiveEntryNotFoundError) return Astro.rewrite('/404');
  return new Response('Changelog temporarily unavailable', { status: 503 });
}

Astro.cache.set(entry);
Astro.cache.set({ maxAge: 300, swr: 60 });

const { Content } = await render(entry);
---
<h1>{entry.data.title}</h1>
<Content />

The error union is narrow: LiveEntryNotFoundError, LiveCollectionValidationError, LiveCollectionCacheHintError, or a generic LiveCollectionError. Because the loader returned a rendered.html property, render() and <Content /> work exactly like they do for Markdown collections.

Caching is what makes this not-a-regression ​

Fetching from a CMS on every request is slower than serving static HTML, and the Astro docs say so plainly. That is where Astro 7's route caching comes in. Configure a provider once (the in-memory one for Node, or the experimental CDN providers for Netlify, Vercel, and Cloudflare) and pass the live entry to Astro.cache.set(). Astro pulls the loader's cache hint off it, tagging the response and setting Last-Modified for you. Multiple set() calls merge: tags accumulate, lastModified takes the newest date, and maxAge is last-write-wins.

Invalidation then becomes a tiny endpoint your CMS webhook can hit:

// src/pages/api/revalidate.ts
export async function POST({ request, cache }) {
  const { id } = await request.json();
  await cache.invalidate({ tags: [`release-${id}`] });
  return Response.json({ purged: id });
}

Notice the inversion. In the classic Jamstack setup, the webhook triggers a full rebuild. Here it purges one cache tag, and the next request fetches fresh data.

When to stay on build-time collections ​

Live collections give up a few things: no MDX rendering at runtime, no image optimization, and no persistence in the content layer data store. If your content changes a few times a week, build-time collections plus a deploy hook are still simpler and faster. Reach for live collections when freshness is the feature: inventory, pricing, changelogs, CMS draft previews, or filters driven by request parameters.

The nice part is you don't have to pick one for the whole site. Both kinds coexist, so your docs can stay static while the one page that always goes stale finally doesn't. Start with the content collections guide and the route caching docs, and try converting your most-complained-about page first.

Nuxt 4.4 shipped a first-party answer: createUseFetch and createUseAsyncData. They are factories that return a composable with the exact same signature as useFetch (or useAsyncData), just with your defaults baked in. No hand-rolled generics, no guessing about keys.

The basic factory ​

The factory lives in your composables/ directory like any other composable. Here is an API client for an external backend, adapted from the recipe in the Nuxt docs:

// app/composables/useAPI.ts
export const useAPI = createUseFetch({
  baseURL: "https://api.example.com",
  onRequest({ options }) {
    const { session } = useUserSession();
    if (session.value?.token) {
      options.headers.set("Authorization", `Bearer ${session.value.token}`);
    }
  },
  async onResponseError({ response }) {
    if (response.status === 401) {
      await navigateTo("/login");
    }
  },
});

Now pages just ask for data:

<script setup lang="ts">
const { data: profile } = await useAPI("/me");
const { data: orders, status } = await useAPI("/orders", { lazy: true });
</script>

useAPI returns the same data, status, error, and refresh you already know, with the same typing. Every option useFetch accepts (query, transform, pick, server, getCachedData, and so on) is still available at the call site.

One rule to remember: createUseFetch is a compiler macro. It has to be an exported declaration in composables/ (or another directory Nuxt scans). That is how Nuxt finds it at build time and injects the de-duplication keys that make SSR hydration reuse the server payload instead of fetching twice. Define it inside a component or a random utility file and you lose that.

Defaults vs. overrides ​

The factory has two modes, and picking the right one matters.

Pass a plain object and your options are defaults. The caller wins on any conflict:

export const useAPI = createUseFetch({
  baseURL: "https://api.example.com",
  lazy: true,
});

// Caller overrides baseURL for this one call
const { data } = await useAPI("/status", {
  baseURL: "https://status.example.com",
});

Pass a function and your options override the caller's. The function receives what the caller passed, so you decide how to merge:

// The base URL is enforced; callers cannot point this client elsewhere
export const useBillingAPI = createUseFetch((callerOptions) => ({
  ...callerOptions,
  baseURL: useRuntimeConfig().public.billingApiUrl,
}));

The function form is also the one to reach for whenever your defaults need something from the Nuxt context, like useRuntimeConfig() or useNuxtApp(). The function runs at the call site, inside setup, where a Nuxt instance exists. A plain object is evaluated once at module scope, where it does not.

A practical way to think about it: object mode for convenience ("most calls want this"), function mode for policy ("every call must have this").

Plugging in a custom $fetch ​

If you already have a configured ofetch instance from a plugin, perhaps with retry logic or logging, you can hand it to the factory:

// app/plugins/api.ts
export default defineNuxtPlugin(() => {
  const api = $fetch.create({
    baseURL: "https://api.example.com",
    retry: 2,
    retryStatusCodes: [502, 503, 504],
  });
  return { provide: { api } };
});

// app/composables/useAPI.ts
export const useAPI = createUseFetch((callerOptions) => ({
  $fetch: useNuxtApp().$api as typeof $fetch,
  ...callerOptions,
}));

Note the function form again: useNuxtApp() has to run in setup, so it cannot sit in a plain object at the top of the file.

createUseAsyncData follows the same pattern for cases where the "fetch" is not an HTTP call at all, such as a GraphQL client, an SDK, or a Supabase query, but you still want shared defaults like lazy, deep, or getCachedData.

When not to bother ​

If your app hits one same-origin /api route and needs no headers, plain useFetch is fine; a factory adds a file and a name for no gain. And remember that useFetch-style composables are for loading data during render. For a form submit or a button click, call $fetch (or your plugin's $api) directly. Wrapping event handlers in useAPI will not give you SSR benefits and can cause confusing caching.

Wrapping up ​

createUseFetch turns a pattern almost every Nuxt team reinvented into one line that keeps full typing and SSR key handling intact. If you are on Nuxt 4.4 or later, look for your existing useFetch wrappers, move them into composables/ as factories, and choose object or function mode deliberately. The createUseFetch docs and the custom useFetch recipe cover the remaining options.

That stops being true this year. TypeScript 6.0 (March 2026) was a deliberate bridge release: it changed a batch of defaults and deprecated a list of legacy options. TypeScript 7.0, the Go-native compiler that went GA in July, keeps the new defaults and removes the deprecated options outright. If you upgraded to 6.0 and silenced the warnings with "ignoreDeprecations": "6.0", you didn't fix anything. You scheduled the breakage for your TS 7 upgrade.

Here's the audit, in the order it will actually bite you.

The two changes with confusing error messages ​

The TypeScript team called these out up front because the errors they produce don't point at the cause.

types now defaults to []. Previously, TypeScript loaded every package under node_modules/@types into the global scope. That's how process, describe, and it showed up without an import. In 6.0 and later, nothing is loaded unless you list it. The symptom is a flood of Cannot find name 'process' or Cannot find name 'describe' errors that look like a broken install.

{
  "compilerOptions": {
    "types": ["node", "vitest/globals"]
  }
}

You can restore the old behavior with "types": ["*"], but don't. The team reports that many projects saw 20 to 50 percent faster builds just from listing the types they actually use, because a typical monorepo transitively drags in hundreds of @types packages nobody imports.

rootDir now defaults to the tsconfig's directory. It used to be inferred from the common ancestor of your source files. If your sources live in src/ and you never set rootDir, your output silently moves from dist/index.js to dist/src/index.js. Nothing errors. Your package.json main field just points at a file that no longer exists.

{
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist"
  },
  "include": ["./src"]
}

If you use a bundler and noEmit, this one won't affect you. If you publish a library with tsc, check it first.

The defaults that flipped quietly ​

These changed in 6.0 and are the baseline in 7.0:

• strict is now true. If you were relying on the old false default, you'll suddenly get every strictNullChecks and noImplicitAny error at once.
• module defaults to esnext, and target floats to the newest supported spec (currently es2025).
• noUncheckedSideEffectImports is true, so a typo in import './polyfil' is now an error instead of a silent no-op.

The honest move with strict is to set it explicitly either way. If your codebase isn't ready, write "strict": false so the decision is visible in the file rather than inherited from a default that changed under you. Then turn on the individual checks one at a time.

The options that are gone in 7.0 ​

These were deprecated in 6.0 and do not exist in 7.0:

baseUrl is the one most frontend projects hit. Almost everyone used it as a prefix for paths, but it was also a lookup root, which meant TypeScript would happily resolve import x from "utils" to src/utils.ts even though no bundler would. The fix is mechanical:

  {
    "compilerOptions": {
-     "baseUrl": "./src",
      "paths": {
-       "@/*": ["*"]
+       "@/*": ["./src/*"]
      }
    }
  }

One related improvement: 6.0 now allows moduleResolution: "bundler" together with module: "commonjs", which is the cleanest landing spot for older projects that still emit CommonJS but used node10 resolution.

Doing the migration without guessing ​

Run your current version with the deprecation warnings visible first. Remove ignoreDeprecations if you added it, run tsc --noEmit, and treat every warning as a ticket. For baseUrl and rootDir, the TypeScript team's experimental ts5to6 codemod will rewrite the config across a monorepo for you.

Once 6.0 is clean, 7.0 should be uneventful for the config side. If you still see odd inference differences, 6.0's --stableTypeOrdering flag makes the JS compiler order types the way the Go compiler does, so you can shake those out before switching binaries.

A tsconfig is supposed to describe what your project actually does. After this cleanup, it finally will: explicit types, explicit rootDir, a moduleResolution that matches your real runtime, and no lookup roots that resolve imports your bundler never could. The full list of changes is in the TypeScript 6.0 release notes, and it's worth one careful read before you bump the version in package.json.

That tax is mostly gone. Type stripping has been on by default since Node 23.6 and 22.18, and as of Node 25.2 and 24.12 the docs mark it Stable. You can type node script.ts and it runs. The catch is that "Node runs TypeScript" is a slightly misleading headline. Node doesn't compile TypeScript. It erases it, and knowing the difference is what keeps you from hitting confusing runtime errors.

Erasing, not compiling ​

When Node loads a .ts, .mts, or .cts file, it hands the source to a small SWC-based module called amaro. Amaro finds the type annotations, interfaces, and type aliases and replaces them with whitespace. What's left is plain JavaScript with the exact same line and column positions, so stack traces point at the right place without source maps.

// greet.ts
interface User {
  name: string;
  visits: number;
}

export function greet(user: User): string {
  return `Welcome back, ${user.name} (${user.visits} visits)`;
}

node greet.ts

Two things this does not do. It doesn't type check: a file full of type errors runs fine as long as the JavaScript underneath is valid. And it doesn't read tsconfig.json at all, so paths, target downleveling, and every other compiler setting are ignored. Your editor and tsc --noEmit in CI are still where type safety lives. Node just stopped making you transpile before you can execute.

The syntax that breaks ​

Because Node only deletes code, anything in TypeScript that generates JavaScript can't work. The big four are enum declarations, namespace blocks with runtime values, constructor parameter properties, and import aliases like import Alias = Some.Namespace. Hit one and Node throws ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX.

// Fails: parameter properties generate assignments
class Repo {
  constructor(private db: Database) {}
}

// Works: the same thing, written as erasable syntax
class Repo {
  private db: Database;
  constructor(db: Database) {
    this.db = db;
  }
}

Enums are the one most teams trip over. A const object with as const gives you the same autocomplete and a real runtime value:

export const Status = {
  Draft: "draft",
  Published: "published",
} as const;

export type Status = (typeof Status)[keyof typeof Status];

There used to be an escape hatch, --experimental-transform-types, that handled enums and friends. Node 26 removed it. If you need full TypeScript semantics at runtime, the docs now point you to a third-party loader like tsx. For everything else, write erasable TypeScript.

Decorators and .tsx files are also out. Decorators wait on native JavaScript support, and JSX needs a real transform.

Let the compiler enforce it for you ​

You don't have to memorize that list. TypeScript 5.8 added erasableSyntaxOnly, which turns every non-erasable construct into a compile error. The Node docs recommend this setup:

{
  "compilerOptions": {
    "noEmit": true,
    "target": "esnext",
    "module": "nodenext",
    "rewriteRelativeImportExtensions": true,
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true
  }
}

verbatimModuleSyntax matters more than it looks. Node can only strip a type import it can recognize, so you must write import type { User } from './user.ts' or import { greet, type User } from './greet.ts'. A plain import { User } is treated as a value import and fails at runtime because nothing named User exists in the emitted JavaScript. This flag makes tsc catch that before Node does.

Two more habits follow from "Node treats .ts like .js." Import specifiers need the real extension (./db.ts, not ./db), and module format follows the nearest package.json "type" field, just like JavaScript. rewriteRelativeImportExtensions lets you keep writing .ts specifiers and still emit working .js if you later publish compiled output.

If you relied on tsconfig paths for aliases like @/lib/db, switch to Node's own subpath imports. They're defined in package.json and must start with #:

{
  "type": "module",
  "imports": {
    "#lib/*": "./src/lib/*"
  }
}

import { connect } from "#lib/db.ts";

Where it fits, and where it doesn't ​

Type stripping shines for scripts, CLIs, internal services, and test files. Pair it with the built-in test runner and a small project can drop ts-node, tsx, and a build step entirely.

It's not for publishing libraries. Node deliberately refuses to strip types from anything under node_modules, so packages still need to ship compiled JavaScript and .d.ts files. And if your codebase leans on enums, decorators, or JSX on the server, a full transpiler remains the right tool.

The practical move this week: add erasableSyntaxOnly to an existing project and see what lights up. If the list is short, you're a few small refactors away from deleting a dependency and a build step. The Node.js TypeScript docs cover the remaining edge cases.

Compression Dictionary Transport fixes exactly that. It became a real standard as RFC 9842 in September 2025, it ships in Chrome and Edge 130+, and Cloudflare opened a beta for it in April 2026. The idea is simple: let the browser tell the server which previous response it has cached, and let the server compress the new response against it. For versioned JavaScript, the result is often a delta measured in single-digit kilobytes.

How the handshake works ​

There are three moving parts: a response that volunteers to be a dictionary, a request that advertises which dictionary is available, and a response compressed with it.

First, the server marks a resource as reusable with the Use-As-Dictionary header. The match value is a URL pattern describing which future requests this file can help with:

HTTP/1.1 200 OK
Content-Type: text/javascript
Cache-Control: public, max-age=31536000
Use-As-Dictionary: match="/js/app.*.js", id="app-v1"

The browser stores that response as a dictionary. The next time it requests something matching /js/app.*.js, say after you deploy app.2d9e44.js, it adds two things to the request: new encodings in Accept-Encoding, and the SHA-256 hash of the dictionary it holds.

GET /js/app.2d9e44.js HTTP/1.1
Accept-Encoding: gzip, br, zstd, dcb, dcz
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Dictionary-ID: "app-v1"

dcb is dictionary-compressed Brotli and dcz is dictionary-compressed Zstandard. If the server has a delta prepared for that exact hash, it responds with one of them:

HTTP/1.1 200 OK
Content-Encoding: dcz
Vary: accept-encoding, available-dictionary

The Vary header is not optional. Without it, a CDN could happily serve a dictionary-compressed body to a client that never had the dictionary, and that client gets garbage. Also note that Dictionary-ID is a convenience label; the server must still verify the Available-Dictionary hash before trusting that the client has the bytes it thinks it has.

Building the deltas at deploy time ​

The practical pattern for static assets is to precompress at build time. For every new bundle, compress it against the previous release's version of the same file and store the result next to it. The Zstandard and Brotli CLIs both accept a dictionary:

# previous release is the dictionary, new build is the payload
zstd -19 --patch-from=dist-prev/app.8f3c1a.js dist/app.2d9e44.js -o dist/app.2d9e44.js.dcz-raw

# the hash the browser will send in Available-Dictionary
openssl dgst -sha256 -binary dist-prev/app.8f3c1a.js | base64

The dcz and dcb formats wrap the compressed stream with a short header that embeds the dictionary hash, so the browser can confirm it decoded against the right file. Tooling like Cloudflare's implementation handles that framing for you; if you roll your own, follow the RFC's format section rather than guessing.

On the server, the logic is a lookup: does a delta exist for this path and this dictionary hash? If yes, serve it. If no, fall back to normal Brotli.

import { createReadStream, existsSync } from "node:fs";

app.get("/js/:file", (req, res, next) => {
  const hash = req.get("available-dictionary")?.slice(1, -1); // strip the colons
  const accepts = req.get("accept-encoding") ?? "";
  const delta = hash && deltaIndex.get(`${req.params.file}:${hash}`);

  res.vary("Accept-Encoding").vary("Available-Dictionary");
  res.set("Use-As-Dictionary", 'match="/js/app.*.js", id="app"');

  if (delta && accepts.includes("dcz") && existsSync(delta)) {
    res.set({ "Content-Encoding": "dcz", "Content-Type": "text/javascript" });
    return createReadStream(delta).pipe(res);
  }
  next(); // regular static handler serves br/gzip
});

Notice the new file also sends Use-As-Dictionary. Each release becomes the dictionary for the next one, so a returning visitor keeps getting deltas across deploys instead of just one.

How big is the win? In Cloudflare's lab test, a 272 KB JavaScript asset was 92.2 KB with gzip. Compressed against its previous version with dcz, it came out at 2.6 KB. Your numbers depend entirely on how much actually changed between builds, but for frequent small deploys that ratio is the whole point.

Shared dictionaries for first visits ​

Deltas only help returning visitors. For first loads, you can ship a separate dictionary built from content common across your pages, like your HTML boilerplate or shared component markup, and hint it to the browser at idle priority:

<link rel="compression-dictionary" href="/dictionary.dat" />

Or with a response header: Link: </dictionary.dat>; rel="compression-dictionary". The browser downloads it in the background, and later page navigations can be compressed against it.

The fine print ​

A few rules will bite you if you skip them. Dictionaries must be same-origin with the resources they compress, and dictionary-compressed responses must be same-origin with the document or served with proper CORS. If you use <link rel="compression-dictionary"> with a Content Security Policy, connect-src has to allow the dictionary URL. Only secure contexts participate.

Browser support is the bigger caveat. Chromium browsers support it today, Firefox has an active implementation bug, and Safari has not announced support. That is fine, because the design degrades gracefully: browsers that don't send dcb or dcz in Accept-Encoding never see a dictionary response and just get your normal Brotli. You are adding a fast path, not a dependency.

If you deploy often and your users come back often, this is one of the rare performance wins that gets bigger the more you ship. Start with your largest versioned JavaScript bundle, precompress one delta per release, and measure transfer size in DevTools on a repeat visit. The MDN guide to compression dictionary transport and the Chrome team's write-up cover the remaining details.

None of those helpers are wrong, exactly. They're just working around the fact that btoa and atob were designed for strings, not bytes. That gap is now closed: Uint8Array has native methods for base64 and hex, in both directions, and they've been Baseline across current Chrome, Firefox, and Safari since September 2025.