Bug: Vite optimizeDeps race condition causes React not found in dev mode

[abcfy2]

Astro Info

Astro                    v6.3.3
Node                     v24.15.0
System                   Linux (x64)
Package Manager          pnpm
Output                   server
Adapter                  @astrojs/node
Integrations             @astrojs/react

If this issue only occurs in one browser, which browser is a problem?

All browsers (tested in Chrome).

Describe the Bug

In dev mode (pnpm dev), when using @astrojs/node adapter + @astrojs/react + Astro Actions + React island with @inlang/paraglide-js and @tailwindcss/vite as Vite plugins, two errors occur:

1. React hydration failure:

[astro-island] Error hydrating /src/components/Counter.tsx
SyntaxError: The requested module "react-dom/client.js"
does not provide an export named "createRoot"

2. Dev toolbar 504:

GET http://localhost:4321/@id/astro/runtime/client/dev-toolbar/entrypoint.js
net::ERR_ABORTED 504 (Outdated Optimize Dep)

After git clean -fdx && pnpm i, Vite's node_modules/.vite/deps/_metadata.json contains only 1 entry:

Total optimized: 1
  astro/actions/runtime/entrypoints/route.js

Expected React entries (react, react-dom, react-dom/client, react/jsx-runtime, @astrojs/react/client.js) are all missing.

pnpm build is NOT affected — production build works correctly.

What's the expected result?

React islands should hydrate and the dev toolbar should load in dev mode without errors. _metadata.json should contain all React dependencies.

Link to Minimal Reproducible Example

https://github.com/abcfy2/astro-react-hydration-bug-repro

git clone https://github.com/abcfy2/astro-react-hydration-bug-repro
cd astro-react-hydration-bug-repro
pnpm i
pnpm dev
# Open http://localhost:4321/ → console shows createRoot error

Related: #16387

[matthewp]

Astrobot, please triage this.

[astrobot-houston]

• Reproduced: No — this is a race condition whose timing depends on machine speed/I/O latency; it did not trigger across 13+ clean-start attempts in the CI sandbox (Linux x86_64, Node v24.15.0), though the reporter observes it consistently with @inlang/paraglide-js + @tailwindcss/vite present.
• Exploration: Yes — View branch
• Unit Test: No — the bug is a timing-dependent race condition in Vite's dep optimizer that cannot be reliably triggered in a unit test.
• Priority: P2: Has Workaround. This affects users running any server adapter + @astrojs/react + Astro Actions in dev mode. The combination is common, but the race condition only manifests under certain timing conditions (influenced by which Vite plugins are loaded). Two simple workarounds exist (see below).

The root cause is in packages/astro/src/vite-plugin-integrations-container/index.ts. The astro:integration-container plugin's buildStart hook runs in all Vite environments — including the client environment — because it lacks an applyToEnvironment filter. When Actions inject a route (astro/actions/runtime/entrypoints/route.js), the buildStart hook calls this.resolve() on it in the client environment, which hits the client dep optimizer's registerMissingImport(). If this races ahead of the optimizer's init() seeding the manually-included deps, the resulting _metadata.json contains only that one entry — wiping react-dom/client and all other pre-bundled React deps.

I wasn't able to find a fix, but I identified some areas that may be relevant. The fix should be to add an applyToEnvironment filter to packages/astro/src/vite-plugin-integrations-container/index.ts to exclude the client environment (using isAstroClientEnvironment from ../environments.js). The buildStart hook only resolves server-side injected route entrypoints, so there is no reason for it to run in the client environment. 27+ other Astro Vite plugins already use this pattern. The configureServer hook is unaffected by applyToEnvironment since it runs from the top-level plugin list, not per-environment. This is functionally the same bug as #16387.

Workaround: Add one of these to your astro.config.mjs:

vite: {
  environments: {
    client: {
      optimizeDeps: { noDiscovery: true }
    }
  }
}

Full Triage Report

Triage Report: Issue #16766

Original Issue

Title: Bug: Vite optimizeDeps race condition causes React not found in dev mode

Author: abcfy2

URL: #16766

Related: #16387 (same root cause, originally reported with @astrojs/cloudflare, now confirmed with @astrojs/node)

Description

In dev mode (pnpm dev), when using @astrojs/node adapter + @astrojs/react + Astro Actions + React island with @inlang/paraglide-js and @tailwindcss/vite as Vite plugins, two errors occur:

1. React hydration failure:

[astro-island] Error hydrating /src/components/Counter.tsx
SyntaxError: The requested module "react-dom/client.js"
does not provide an export named "createRoot"

2. Dev toolbar 504:

GET http://localhost:4321/@id/astro/runtime/client/dev-toolbar/entrypoint.js
net::ERR_ABORTED 504 (Outdated Optimize Dep)

After git clean -fdx && pnpm i, Vite's node_modules/.vite/deps/_metadata.json contains only 1 entry (astro/actions/runtime/entrypoints/route.js). Expected React entries (react, react-dom, react-dom/client, react/jsx-runtime, @astrojs/react/client.js) are all missing.

pnpm build is NOT affected — production build works correctly.

Expected: React islands should hydrate and the dev toolbar should load in dev mode without errors. _metadata.json should contain all React dependencies.

Environment

Reporter's environment:

• Astro v6.3.3
• Node v24.15.0
• Linux (x64)
• pnpm
• Output: server
• Adapter: @astrojs/node
• Integrations: @astrojs/react
• Additional Vite plugins: @inlang/paraglide-js, @tailwindcss/vite

Reproduction environment:

• Astro v6.3.3 (workspace packages from monorepo)
• Node v24.15.0
• Linux (x64)
• pnpm v11.0.9

Reproduction Steps

1. Cloned the reporter's reproduction repo: https://github.com/abcfy2/astro-react-hydration-bug-repro
2. Modified package.json to use workspace:* references for astro, @astrojs/node, and @astrojs/react
3. Ran pnpm install --no-frozen-lockfile successfully
4. Cleaned .vite cache and .astro directory
5. Started dev server with pnpm dev
6. Opened page in browser and checked for hydration errors
7. Inspected _metadata.json for optimized dependency entries

Reproduction project files:

• astro.config.mjs: Configures output: "server", adapter: node({ mode: "standalone" }), integrations: [react()], and Vite plugins (paraglideVitePlugin, tailwindcss())
• src/pages/index.astro: Simple page with a React island (<Counter client:load />)
• src/components/Counter.tsx: Simple React counter component with useState
• src/actions/index.ts: Defines a trivial action (ping returning "pong")

Results: NOT REPRODUCED

Across 13+ clean-start attempts (each with a freshly deleted .vite cache), the bug did not reproduce:

• _metadata.json consistently contained 10 optimized entries, including all expected React dependencies: react, react-dom, react-dom/client, react/jsx-runtime, react/jsx-dev-runtime, @astrojs/react/client.js
• The React island hydrated successfully — clicking the counter button correctly incremented the count
• No console errors appeared in the browser (no createRoot SyntaxError, no 504 on dev toolbar)
• The dev toolbar loaded correctly with all its buttons (Menu, Inspect, Audit, Settings)
• pnpm build also worked correctly (as the reporter noted)

Analysis

This is a race condition — the underlying code defect IS present

Even though the bug didn't reproduce in our specific sandbox timing, the underlying code defect is real and confirmed by code analysis and the related issue #16387. This is the same bug.

Root Cause

The root cause is in packages/astro/src/vite-plugin-integrations-container/index.ts. The astro:integration-container Vite plugin's buildStart hook runs in all environments (including the client environment) because it lacks an applyToEnvironment filter.

// packages/astro/src/vite-plugin-integrations-container/index.ts
return {
    name: 'astro:integration-container',
    // NOTE: no applyToEnvironment filter!
    async configureServer(server) { ... },
    async buildStart() {
        if (settings.injectedRoutes.length === settings.resolvedInjectedRoutes.length) return;
        settings.resolvedInjectedRoutes = await Promise.all(
            settings.injectedRoutes.map((route) => resolveEntryPoint.call(this, route)),
        );
    },
};

When this buildStart hook runs in the client environment:

1. It calls this.resolve('astro/actions/runtime/entrypoints/route.js') (the injected action route)
2. The resolve call flows through Vite's tryNodeResolve and reaches the client dep optimizer's registerMissingImport()
3. If this registration races ahead of the dep optimizer's init() seeding addManuallyIncludedOptimizeDeps(), the debounced processing produces a _metadata.json containing only that one entry
4. This wipes react-dom/client and other pre-bundled deps
5. The browser then fetches raw CJS react-dom/client, which throws SyntaxError: does not provide an export named 'createRoot'

Why it doesn't reproduce consistently

The race condition timing depends on machine speed, I/O latency, and which Vite plugins are present (they affect startup timing). In our sandbox (Linux x86_64, Node v24.15.0), the dep optimizer init apparently completes before the buildStart hook's resolve call reaches the client dep optimizer.

The presence of @inlang/paraglide-js and @tailwindcss/vite (mentioned by this issue's reporter) likely affects timing enough to change the race outcome. The reporter's README notes that the bug is consistent on their system but may be intermittent on others.

Why build is not affected

astro build uses Rollup (not Vite's dev dep optimizer) to handle CJS→ESM conversion, which works reliably regardless of race conditions.

Code evidence

• 27+ other Astro Vite plugins already use applyToEnvironment to restrict which environments they run in (confirmed by grep -rn "applyToEnvironment" packages/astro/src/)
• The astro:integration-container plugin does NOT use applyToEnvironment
• The buildStart hook only resolves server-side injected route entrypoints — there's no legitimate reason for it to run in the client environment
• The actions integration (packages/astro/src/actions/integration.ts) injects the route 'astro/actions/runtime/entrypoints/route.js' which is the entry that corrupts the client optimizer
• The separate @astro/plugin-actions-build plugin already correctly uses applyToEnvironment to restrict to server environments

Suggested Fix

Add an applyToEnvironment filter to exclude the client environment:

import { isAstroClientEnvironment } from '../environments.js';

return {
    name: 'astro:integration-container',
    applyToEnvironment(environment) {
        return !isAstroClientEnvironment(environment);
    },
    async configureServer(server) { ... },
    async buildStart() { ... },
};

This is safe because:

• The buildStart hook resolves server-only injected routes — there's no reason to run it in the client environment
• configureServer is executed from the top-level plugin list, not via the per-environment pipeline, so applyToEnvironment has no effect on it
• The state is shared via the settings closure, so other non-client envs will populate resolvedInjectedRoutes correctly

Workarounds

Users can work around the issue with either of these in astro.config.mjs:

vite: {
  environments: {
    client: {
      optimizeDeps: { noDiscovery: true }
    }
  }
}

Or:

vite: {
  optimizeDeps: {
    include: ['astro/actions/runtime/entrypoints/route.js'],
  },
}

Duplicate Status

This issue is functionally a duplicate of #16387, which describes the same root cause. Issue #16387 was originally about @astrojs/cloudflare, but comments on that issue confirm the same problem occurs with @astrojs/node and potentially any adapter. This new issue #16766 adds the specific combination with @inlang/paraglide-js and @tailwindcss/vite as additional context about what affects the race condition timing.

This report was made by an LLM. The analysis may be wrong, and the potential fix might not work, but is intended as a starting point for exploring the issue.

[matthewp]

Astrobot, if we added react as an optimized dep wouldn't that fix this? Do we not currently have these listed? Try this method out.

[astrobot-houston]

• Reproduced: No — structurally impossible to reproduce in the monorepo workspace (see explanation below), though the underlying code defect is confirmed via Vite source analysis.
• Exploration: Yes — View branch
• Unit Test: No — the bug is a timing-dependent race condition in Vite's dep optimizer that cannot be reliably triggered in a unit test, and cannot be triggered at all in the monorepo workspace.
• Priority: P2: Has Workaround. This affects users running any server adapter + @astrojs/react + Astro Actions in dev mode. The combination is common, but the race condition only manifests under certain timing conditions (influenced by which Vite plugins are loaded). Two simple workarounds exist.

The root cause is in packages/astro/src/vite-plugin-integrations-container/index.ts. The astro:integration-container plugin's buildStart hook runs in all Vite environments — including the client environment — because it lacks an applyToEnvironment filter. When Actions inject a route (astro/actions/runtime/entrypoints/route.js), the buildStart hook calls this.resolve() on it in the client environment, which hits the client dep optimizer's registerMissingImport(). This triggers a 100ms debounce timer that can fire before depsOptimizer.init() seeds the manually-included deps, causing _metadata.json to contain only that one entry — wiping all pre-bundled React deps. This is functionally the same bug as #16387.

To answer the specific question about React optimized deps: React deps are already listed — @astrojs/react's configEnvironmentPlugin already adds react, react/jsx-runtime, react/jsx-dev-runtime, react-dom, react-dom/client, and @astrojs/react/client.js to environments.client.optimizeDeps.include. Adding them again (in any form) wouldn't fix the race because all optimizeDeps.include entries are processed during depsOptimizer.init() via addManuallyIncludedOptimizeDeps() — and that's the exact function that gets short-circuited when the debounce timer fires first and writes a premature cache that init() then reads and accepts.

I wasn't able to find a fix, but I identified some areas that may be relevant. The fix should be to add an applyToEnvironment filter to packages/astro/src/vite-plugin-integrations-container/index.ts to exclude the client environment (using isAstroClientEnvironment from ../environments.js). The buildStart hook only resolves server-side injected route entrypoints, so there is no reason for it to run in the client environment. 27+ other Astro Vite plugins already use this pattern. The configureServer hook is unaffected by applyToEnvironment since it runs from the top-level plugin list, not per-environment.

Why it can't be reproduced in the monorepo: When astro is a workspace link, astro/actions/runtime/entrypoints/route.js resolves to a path outside node_modules. Vite's vite:resolve plugin has an early return if (!isInNodeModules(resolved)) that skips registerMissingImport() entirely. When installed from npm, the path IS in node_modules, so the race condition path is reachable. This is a structural limitation of our test sandbox, not a timing issue.

Workaround: Add one of these to your astro.config.mjs:

vite: {
  environments: {
    client: {
      optimizeDeps: { noDiscovery: true }
    }
  }
}

Full Triage Report

Triage Report: Issue #16766

Original Issue

Title: Bug: Vite optimizeDeps race condition causes React not found in dev mode

Author: abcfy2

URL: #16766

Related: #16387 (same root cause, originally reported with @astrojs/cloudflare, now confirmed with @astrojs/node)

Description

In dev mode (pnpm dev), when using @astrojs/node adapter + @astrojs/react + Astro Actions + React island with @inlang/paraglide-js and @tailwindcss/vite as Vite plugins, two errors occur:

1. React hydration failure:

[astro-island] Error hydrating /src/components/Counter.tsx
SyntaxError: The requested module "react-dom/client.js"
does not provide an export named "createRoot"

2. Dev toolbar 504:

GET http://localhost:4321/@id/astro/runtime/client/dev-toolbar/entrypoint.js
net::ERR_ABORTED 504 (Outdated Optimize Dep)

After git clean -fdx && pnpm i, Vite's node_modules/.vite/deps/_metadata.json contains only 1 entry (astro/actions/runtime/entrypoints/route.js). Expected React entries (react, react-dom, react-dom/client, react/jsx-runtime, @astrojs/react/client.js) are all missing.

pnpm build is NOT affected — production build works correctly.

Expected: React islands should hydrate and the dev toolbar should load in dev mode without errors. _metadata.json should contain all React dependencies.

Environment

Reporter's environment:

• Astro v6.3.3
• Node v24.15.0
• Linux (x64)
• pnpm
• Output: server
• Adapter: @astrojs/node
• Integrations: @astrojs/react
• Additional Vite plugins: @inlang/paraglide-js, @tailwindcss/vite

Reproduction environment:

• Astro v6.3.3 (workspace packages from monorepo)
• Node v24.15.0
• Linux (x64)
• pnpm v11.0.9

Reproduction Steps

1. Cloned the reporter's reproduction repo: https://github.com/abcfy2/astro-react-hydration-bug-repro
2. Modified package.json to use workspace:* references for astro, @astrojs/node, and @astrojs/react
3. Ran pnpm install --no-frozen-lockfile successfully
4. Cleaned .vite cache and .astro directory
5. Started dev server with pnpm dev
6. Checked _metadata.json for optimized dependency entries
7. Verified page loads correctly in browser

Reproduction project files:

• astro.config.mjs: Configures output: "server", adapter: node({ mode: "standalone" }), integrations: [react()], and Vite plugins (paraglideVitePlugin, tailwindcss())
• src/pages/index.astro: Simple page with a React island (<Counter client:load />)
• src/components/Counter.tsx: Simple React counter component with useState
• src/actions/index.ts: Defines a trivial action (ping returning "pong")

Results: NOT REPRODUCED — But Root Cause Confirmed via Code Analysis

The bug did not reproduce in our sandbox. _metadata.json consistently contained 10 optimized entries, including all expected React dependencies. The React island hydrated successfully and the dev toolbar loaded correctly.

Why It Cannot Be Reproduced in the Monorepo Workspace

Critical finding: The bug is structurally impossible to reproduce when using workspace:* references in the monorepo.

When astro is a workspace link (workspace:*), the module astro/actions/runtime/entrypoints/route.js resolves to /workspace/packages/astro/dist/actions/runtime/entrypoints/route.js — a path that is NOT inside node_modules. Vite's vite:resolve plugin has an early return condition:

if (!isInNodeModules(resolved) || !depsOptimizer || options.scan) 
    return { id: resolved };

Since isInNodeModules() returns false for workspace-linked paths, registerMissingImport() is never called, and the race condition cannot be triggered.

When installed from npm (as the reporter does), astro resolves to a path inside node_modules, so isInNodeModules() returns true, and the full registerMissingImport → debounce → race condition path is possible.

Maintainer's Specific Question

@matthewp asked: "if we added react as an optimized dep wouldn't that fix this? Do we not currently have these listed?"

Answer: React IS Already Listed

The @astrojs/react integration already adds React deps to optimizeDeps.include for the client environment via its configEnvironmentPlugin:

// packages/integrations/react/src/index.ts, lines 128-150
configEnvironment(environmentName, options): EnvironmentOptions {
    if (environmentName === 'client' || ...) {
        finalOptions.optimizeDeps!.include = [
            'react',
            'react/jsx-runtime',
            'react/jsx-dev-runtime',
            'react-dom',
        ];
        if (environmentName === 'client') {
            finalOptions.optimizeDeps!.include.push('react-dom/client');
            finalOptions.optimizeDeps!.include.push(reactConfig.client); // @astrojs/react/client.js
        }
    }
}

Why Adding Them "More" Wouldn't Fix the Race

The race condition occurs in this sequence (Vite 7.x source analysis):

1. DevEnvironment constructor creates depsOptimizer with empty metadata and inited = false
2. initServer() calls await environments.client.pluginContainer.buildStart()
3. During buildStart, astro:integration-container calls this.resolve('astro/actions/runtime/entrypoints/route.js') in the client environment
4. Vite's vite:resolve plugin resolves this, finds it's in node_modules + optimizable, calls depsOptimizer.registerMissingImport()
5. Since waitingForCrawlEnd is still false (set to true only in init()), debouncedProcessing() starts a 100ms debounce timer
6. buildStart() completes
7. listen() is called → depsOptimizer.init() starts
8. init() tries to loadCachedDepOptimizationMetadata() — but the 100ms debounce timer from step 5 may fire and call runOptimizer() before init() finishes
9. If runOptimizer() fires first, it processes only the 1 discovered dep (actions route), writes _metadata.json with just that entry
10. When init() calls loadCachedDepOptimizationMetadata(), it finds the just-written cache (with only 1 dep) and uses it — the if (!cachedMetadata) branch that calls addManuallyIncludedOptimizeDeps() is SKIPPED
11. Result: React deps are never added to the optimizer despite being in optimizeDeps.include

All optimizeDeps.include entries are only processed inside init() via addManuallyIncludedOptimizeDeps(). Adding React to optimizeDeps.include in any additional way would NOT help because the race short-circuits that entire code path.

What Would Actually Fix This

Add an applyToEnvironment filter to the integration container plugin:

import { isAstroClientEnvironment } from '../environments.js';

return {
    name: 'astro:integration-container',
    applyToEnvironment(environment) {
        return !isAstroClientEnvironment(environment);
    },
    // ... rest unchanged
};

This prevents buildStart from running in the client environment entirely, so this.resolve() never touches the client dep optimizer. 27+ other Astro Vite plugins already use this pattern.

Key Files and Code Paths

Astro source files involved:

• packages/astro/src/vite-plugin-integrations-container/index.ts — The plugin whose buildStart triggers the race (missing applyToEnvironment filter)
• packages/astro/src/actions/integration.ts — Injects astro/actions/runtime/entrypoints/route.js as a route
• packages/integrations/react/src/index.ts — configEnvironmentPlugin that already adds React deps to optimizeDeps.include
• packages/astro/src/vite-plugin-environment/index.ts — Sets optimizeDeps for client environment (dev toolbar entries)

Vite source paths involved (v7.3.2):

• vite:resolve plugin resolveId → calls registerMissingImport() for bare imports resolving to node_modules
• createDepsOptimizer() → creates optimizer with empty metadata
• depsOptimizer.init() → called during DevEnvironment.listen(), loads cache or runs addManuallyIncludedOptimizeDeps
• registerMissingImport() → adds dep to discovered, calls debouncedProcessing() (100ms)
• loadCachedDepOptimizationMetadata() → reads _metadata.json cache; if found, skips manual includes

Execution order that creates the race:

DevEnvironment constructor → creates depsOptimizer (empty metadata)
  ↓
initServer() → await pluginContainer.buildStart()
  ↓
astro:integration-container buildStart → this.resolve('astro/actions/runtime/entrypoints/route.js')
  ↓
vite:resolve → isInNodeModules(resolved) → true → registerMissingImport()
  ↓
debouncedProcessing(100ms) timer starts
  ↓
buildStart() completes
  ↓
listen() → depsOptimizer.init()
  ↓
Race: does debounce timer fire before init() finishes?
  Yes → only actions route optimized, React lost
  No  → init() seeds manual includes, React included

Workarounds

Users can work around the issue with either of these in astro.config.mjs:

vite: {
  environments: {
    client: {
      optimizeDeps: { noDiscovery: true }
    }
  }
}

Or:

vite: {
  optimizeDeps: {
    include: ['astro/actions/runtime/entrypoints/route.js'],
  },
}

Duplicate Status

This issue is functionally a duplicate of #16387, which describes the same root cause. Issue #16387 was originally about @astrojs/cloudflare, but comments on that issue confirm the same problem occurs with @astrojs/node and potentially any adapter.

This report was made by an LLM. The analysis may be wrong, and the potential fix might not work, but is intended as a starting point for exploring the issue.

[abcfy2]

vite: {
  environments: {
    client: {
      optimizeDeps: { noDiscovery: true }
    }
  }
}

This no help and will cause another issue:

[astro-island] Error hydrating /src/components/training/LearningPathFlow.tsx SyntaxError: The requested module '/node_modules/.pnpm/use-sync-external-store@1.6.0_react@19.2.6/node_modules/use-sync-external-store/shim/with-selector.js?v=2d55dece' does not provide an export named 'default' (at traditional.mjs:2:8)

[abcfy2]

The noDiscovery: true workaround is too aggressive — it disables all dependency discovery, causing indirect deps like use-sync-external-store to not be optimized.

This workaround is more targeted and works in our production project:

// astro.config.mjs — vite.plugins
{
  name: "fix-react-optimize-deps",
  enforce: "pre",
  config() {
    return {
      environments: {
        client: {
          optimizeDeps: {
            exclude: ["astro/actions/runtime/entrypoints/route.js"],
            include: [
              "react",
              "react/jsx-runtime",
              "react/jsx-dev-runtime",
              "react-dom",
              "react-dom/client",
              "@astrojs/react/client.js",
            ],
          },
        },
      },
    };
  },
},

• exclude prevents route.js from being registered in the client optimizer (the source of the race)
• include explicitly seeds React deps so they are always pre-bundled regardless of timing
• enforce: "pre" ensures this runs before buildStart
• Normal dependency discovery still works, so indirect deps continue to be optimized correctly

[Prayaksh]

I investigated this further and it looks like the issue is coming from astro:integration-container running its buildStart() hook in the client Vite environment.

That hook resolves injected routes like:

astro/actions/runtime/entrypoints/route.js

which appears to register a missing import in the client dep optimizer during startup. If this happens before optimizeDeps initialization finishes, the optimizer cache can end up containing only the injected route entry and skip the manually included React deps (react-dom/client, @astrojs/react/client.js, etc.).

I tested adding:

applyToEnvironment(environment) {
  return environment.name !== 'client';
}

to src/vite-plugin-integrations-container/index.ts.

After this change, the plugin no longer runs in the client environment, which seems correct since the hook only resolves server-side injected routes.

[matthewp]

Yeah noDiscovery is never the solution for this kind of thing. Thanks @Prayaksh, will try your idea.

[matthewp]

Can anyone try with:

npm i https://pkg.pr.new/astro@16770