deps: upgrade to nuxt-nightly (5x) and vite ^8.1 - #1048
Conversation
Bumps nuxt to npm:nuxt-nightly@5x and vite to ^8.1.5 (removing the prior ~8.0.16 pin, which existed only because @vitejs/devtools 0.4.2 broke under vite 8.1's WebSocket-upgrade handling — no longer reproducible against the current @vitejs/devtools 0.4.9 e2e SSR suite). Nuxt 5 nightly builds on the next-gen Nitro v3 engine (package `nitro`, not `nitropack`), which required several compatibility fixes: - `unplugin-vue-markdown`'s vite plugin now needs `prepend: true` when registered via `addVitePlugin`, since Nuxt's non-isomorphic plugin wrapping otherwise hard-codes `enforce: 'post'`, discarding the plugin's own `enforce: 'pre'` and breaking `.md` SFC compilation. - The DevTools storage browser rebuilds its own `unstorage` instance from `nitro.options.storage`/`devStorage` instead of reading `nitro.storage`, which Nitro v3 no longer exposes (storage is now a build-time virtual module). This was crashing SSR prerendering with 500s under Nitro v3. `server-routes`/`server-tasks` similarly move from watching the (now gone) internal `src` storage mount to Nitro's `dev:reload` hook. `data-inspector`, `module-main`, and `runtime/nitro/inline` are updated for the Nitro v2/v3 union types Nuxt 5's hooks now carry. - The Components tab's built-in-vs-library grouping recognized only the literal `nuxt` package name; `nuxt-nightly` (and the older `nuxt-edge` alias) are now recognized too. - Pin `vue-sfc-transformer` to what `@nuxt/module-builder`'s bundled `mkdist` actually depends on (`^0.1.17`) — `resolutionMode: highest` otherwise hoists it to module-builder's own newer want, and mkdist's `.vue` transform silently breaks under that mismatch, writing compiled output into `packages/devtools/src/runtime/**` instead of `dist/`. Known remaining issue: `floating-vue`'s globally-registered `<VDropdown>` fails to render its scoped-slot content under this stack (upstream, unresolved — Akryum/floating-vue#924, #1085), so component/composable/route names inside their dropdown triggers don't render in the DevTools UI. The underlying data is unaffected; this is UI-only and tracked as a follow-up. pnpm build, pnpm typecheck, pnpm lint, and pnpm test all pass. This upgrade was done with the help of an AI agent.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe changes add Nitro v2/v3 compatibility types and update DevTools configuration, lifecycle, route, task, and storage integration. Client package classification, markdown plugin ordering, route highlighting, and server handler registration are adjusted. Nuxt 4 and Nuxt 5 ecosystem playgrounds become root workspace members with dedicated scripts, CI checks, documentation, and a generated Nitro type-resolution verification script. Estimated code review effort: 4 (Complex) | ~60 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 2⚔️ Resolve merge conflicts 💡
🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
@nuxt/devtools and @nuxt/devtools-kit only ever consume one or the other at runtime (whichever Nitro engine the consumer's own Nuxt resolves), so declare both as optional peerDependencies rather than as plain dependencies of the published package. This monorepo still pins a devDependency on each (via the shared catalog) so its own build and typecheck resolve a single, consistent version of both instead of whatever `autoInstallPeers` would otherwise pick independently. devtools-kit only type-imports from `nitropack` (not `nitro/types`), so it only declares the `nitropack` peer.
…e nitro type resolution Adds two sealed production playgrounds under `playgrounds-ecosystem/` that link the local `@nuxt/devtools` and are verified with `nuxi typecheck` + a production `nuxi build`: - `nuxt4/` — Nuxt 4.5.1 (stable), which ships Nitro v2 (`nitropack`) only - `nuxt5/` — nuxt-nightly 5x, which ships Nitro v3 (`nitro`) only proving this repo's DevTools loads, type-checks, and builds against a consumer on either Nuxt major / Nitro engine. Both pass. Wired into the (manual) ecosystem-playground CI workflow. Type resolution when only one engine exists -------------------------------------------- Made the Nitro type references resilient to the optional-peer setup: a missing `nitro`/`nitropack` resolves its `import type` to `any`, which a naive `NitroV2 | NitroV3` union collapses to `any` (dropping all safety on the engine that IS present). `packages/*/src/**/nitro-compat.ts` now detect which package actually resolved (probing an impossible `'___INVALID'` key — the same trick `@nuxt/kit` uses) and resolve to just that one: - only `nitro` → concrete Nitro v3 type - only `nitropack` → concrete Nitro v2 type `@nuxt/devtools-kit` grows the same detection (`_types/nitro-compat.ts`, used by `rpc.ts`), declares `nitro` as an optional peer + pins both as devDeps for a single consistent monorepo version, and externalizes `nitro`/`nitro/types` in its unbuild config. A committed, reproducible check — `playgrounds-ecosystem/scripts/check-nitro-type-resolution.mjs` — asserts all of the above (incl. a control proving the naive union degrades to `any`). Incidental: the `nuxt-nightly@5x` tag re-resolved on reinstall (a floating tag drifts whenever package.json changes), whose newer typed-routes surfaced a `route.params.id` type error in the generic `ModuleTreeNode.vue` — read the param defensively.
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@playgrounds-ecosystem/nuxt4/package.json`:
- Around line 12-18: Move the versions for `@types/node`, nuxt, typescript, and
vue-tsc from the nuxt4 package manifest into named entries in
pnpm-workspace.yaml, then replace their raw version ranges in the
devDependencies block with the corresponding catalog:<name> references. Keep the
existing version values unchanged.
In `@playgrounds-ecosystem/nuxt5/package.json`:
- Around line 12-17: Update the devDependencies in the nuxt5 package manifest to
use the existing pnpm catalog specifiers for `@types/node`, typescript, and
vue-tsc, referencing their respective types or cli catalog entries. Preserve the
local `@nuxt/devtools` link and nightly Nuxt alias.
In `@playgrounds-ecosystem/scripts/check-nitro-type-resolution.mjs`:
- Around line 44-51: Update the COMPAT fixture generation in the script around
the Nitro compatibility declaration check to load and exercise the shipped
nitro-compat.ts declaration sources from both `@nuxt/devtools` and
`@nuxt/devtools-kit`, rather than maintaining a duplicated inline declaration.
Ensure the script validates both packages’ generated compatibility declarations
so divergence is detected.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 4c18a98e-bbd8-4b1a-955e-8fd4152662b2
⛔ Files ignored due to path filters (3)
playgrounds-ecosystem/nuxt4/pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlplaygrounds-ecosystem/nuxt5/pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (23)
.github/workflows/ecosystem-playground.ymlpackages/devtools-kit/build.config.tspackages/devtools-kit/package.jsonpackages/devtools-kit/src/_types/nitro-compat.tspackages/devtools-kit/src/_types/rpc.tspackages/devtools/client/components/ModuleTreeNode.vuepackages/devtools/src/server-rpc/storage.tspackages/devtools/src/utils/nitro-compat.tsplaygrounds-ecosystem/README.mdplaygrounds-ecosystem/REPORTS.mdplaygrounds-ecosystem/nuxt4/.npmrcplaygrounds-ecosystem/nuxt4/app.vueplaygrounds-ecosystem/nuxt4/nuxt.config.tsplaygrounds-ecosystem/nuxt4/package.jsonplaygrounds-ecosystem/nuxt4/pnpm-workspace.yamlplaygrounds-ecosystem/nuxt4/tsconfig.jsonplaygrounds-ecosystem/nuxt5/.npmrcplaygrounds-ecosystem/nuxt5/app.vueplaygrounds-ecosystem/nuxt5/nuxt.config.tsplaygrounds-ecosystem/nuxt5/package.jsonplaygrounds-ecosystem/nuxt5/pnpm-workspace.yamlplaygrounds-ecosystem/nuxt5/tsconfig.jsonplaygrounds-ecosystem/scripts/check-nitro-type-resolution.mjs
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/devtools/src/server-rpc/storage.ts
| "devDependencies": { | ||
| "@nuxt/devtools": "link:../../packages/devtools", | ||
| "@types/node": "^26.1.1", | ||
| "nuxt": "^4.5.1", | ||
| "typescript": "^6.0.3", | ||
| "vue-tsc": "^3.3.8" | ||
| } |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/sh
set -eu
sed -n '1,220p' playgrounds-ecosystem/nuxt4/pnpm-workspace.yaml
rg -n -C2 'catalog:|catalogs:' pnpm-workspace.yaml playgrounds-ecosystem/nuxt4/pnpm-workspace.yaml 2>/dev/null || trueRepository: nuxt/devtools
Length of output: 685
🏁 Script executed:
#!/bin/sh
set -eu
echo "== root pnpm-workspace catalogs around dependency names =="
rg -n -C3 'catalogs:|catalog:|typescript:|vue-tsc:|`@types/node`:|nuxt:' pnpm-workspace.yaml packages playgrounds-ecosystem 2>/dev/null | head -n 260
echo
echo "== nuxt4 package and workspace =="
cat -n playgrounds-ecosystem/nuxt4/package.json
cat -n playgrounds-ecosystem/nuxt4/pnpm-workspace.yamlRepository: nuxt/devtools
Length of output: 20527
Use catalog-managed dependency versions.
This workspace’s pnpm-workspace.yaml does not define catalog entries for @types/node, nuxt, typescript, or vue-tsc, so these packages would remain raw ranges and can drift outside the workspace compatibility matrix. Move these ranges into pnpm-workspace.yaml and reference them with catalog:<name>.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@playgrounds-ecosystem/nuxt4/package.json` around lines 12 - 18, Move the
versions for `@types/node`, nuxt, typescript, and vue-tsc from the nuxt4 package
manifest into named entries in pnpm-workspace.yaml, then replace their raw
version ranges in the devDependencies block with the corresponding
catalog:<name> references. Keep the existing version values unchanged.
Source: Coding guidelines
| "devDependencies": { | ||
| "@nuxt/devtools": "link:../../packages/devtools", | ||
| "@types/node": "^26.1.1", | ||
| "nuxt": "npm:nuxt-nightly@5x", | ||
| "typescript": "^6.0.3", | ||
| "vue-tsc": "^3.3.8" |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== files =="
git ls-files | sed -n '/package.json$/p'
echo
echo "== target package.json =="
cat -n playgrounds-ecosystem/nuxt5/package.json
echo
echo "== root package manager/catalog references =="
for f in package.json pnpm-workspace.yaml .npmrc; do
if [ -f "$f" ]; then
echo "--- $f ---"
sed -n '1,220p' "$f"
fi
done
echo
echo "== catalog references in package.json files =="
python3 - <<'PY'
import json, pathlib
for p in sorted(pathlib.Path('.').rglob('package.json')):
if any(part in ('node_modules','.git') for part in p.parts):
continue
try:
data=json.loads(p.read_text())
except Exception as e:
print(f"ERROR {p}: {e}")
continue
print(f"--- {p} ---")
for sec in ['dependencies','devDependencies','optionalDependencies','peerDependencies','packageManager']:
if sec in data:
print(sec, data[sec])
PY
echo
echo "== pnpm catalog config refs =="
rg -n "catalog:|pnpm/catal|catalog" . -g '!node_modules' -g '!dist' -g '!build' | sed -n '1,220p'Repository: nuxt/devtools
Length of output: 32316
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== playgrounds-ecosystem pnpm workspace/config =="
sed -n '1,120p' playgrounds-ecosystem/modules/pnpm-workspace.yaml
cat -n playgrounds-ecosystem/modules/package.json
echo
echo "== root package.json catalog configuration sections =="
python3 - <<'PY'
import json
from pathlib import Path
data = json.loads(Path("package.json").read_text())
print("packageManager:", data.get("packageManager"))
for key in ["catalog","catalogs"]:
print(f"\n[{key}]")
val = data.get(key)
if isinstance(val, dict):
for k,v in val.items():
if k in ("packages","ignoredNonCatalogDependencies"):
print(k, v)
elif key == "catalogs":
print(f"\n-- {k} --")
for name, version in v.items():
print(f"{name}: {version}")
PYRepository: nuxt/devtools
Length of output: 1427
Use pnpm catalog references for the registry toolchain deps.
@types/node, typescript, and vue-tsc are declared with raw ranges in playgrounds-ecosystem/nuxt5/package.json. These are currently covered by root catalog entries (@types/node in types, typescript and vue-tsc in cli), so switch them to the matching catalog:<name> specifiers. Keep the local DevTools link and nightly Nuxt alias only if they cannot be represented as catalog entries.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@playgrounds-ecosystem/nuxt5/package.json` around lines 12 - 17, Update the
devDependencies in the nuxt5 package manifest to use the existing pnpm catalog
specifiers for `@types/node`, typescript, and vue-tsc, referencing their
respective types or cli catalog entries. Preserve the local `@nuxt/devtools` link
and nightly Nuxt alias.
Sources: Coding guidelines, MCP tools
| // The detection shipped in packages/*/src/**/nitro-compat.ts, as a `.d.ts`. | ||
| const COMPAT = `import type { Nitro as NitroV3 } from 'nitro/types' | ||
| import type { Nitro as NitroV2 } from 'nitropack' | ||
| export type HasNitroV2 = 'options' extends keyof NitroV2 ? ('___INVALID' extends keyof NitroV2 ? false : true) : false | ||
| export type HasNitroV3 = 'options' extends keyof NitroV3 ? ('___INVALID' extends keyof NitroV3 ? false : true) : false | ||
| export type AnyNitro = HasNitroV2 extends true ? (HasNitroV3 extends true ? NitroV2 | NitroV3 : NitroV2) : NitroV3 | ||
| export type NaiveAnyNitro = NitroV2 | NitroV3 | ||
| ` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/sh
set -eu
rg -n -C3 --glob 'nitro-compat.ts' 'HasNitroV2|HasNitroV3|AnyNitro' packages
rg -n -C3 'COMPAT|nitro-compat\.d\.ts' playgrounds-ecosystem/scripts/check-nitro-type-resolution.mjsRepository: nuxt/devtools
Length of output: 4385
🏁 Script executed:
#!/bin/sh
set -eu
printf '--- script outline ---\n'
ast-grep outline playgrounds-ecosystem/scripts/check-nitro-type-resolution.mjs --view expanded || true
printf '\n--- script relevant contents ---\n'
sed -n '1,180p' playgrounds-ecosystem/scripts/check-nitro-type-resolution.mjs
printf '\n--- canonical nitro-compat files ---\n'
cat -n packages/devtools/src/utils/nitro-compat.ts
printf '\n--- devtools-kit ---\n'
cat -n packages/devtools-kit/src/_types/nitro-compat.ts
printf '\n--- diff/stat summary ---\n'
git diff --stat
git diff -- playgrounds-ecosystem/scripts/check-nitro-type-resolution.mjs packages/devtools/src/utils/nitro-compat.ts packages/devtools-kit/src/_types/nitro-compat.ts | sed -n '1,220p'
printf '\n--- find package manifests referencing deps/scripts ---\n'
rg -n '"(prepare|build|typecheck|test)"|"nitro(@|:|")|nitropack"|"nitro-compat"' package.json pnpm-workspace.yaml packages/**/*.json playgrounds-ecosystem -S || trueRepository: nuxt/devtools
Length of output: 242
🏁 Script executed:
#!/bin/sh
set -eu
echo '--- script outline ---'
ast-grep outline playgrounds-ecosystem/scripts/check-nitro-type-resolution.mjs --view expanded || true
echo
echo '--- script relevant contents ---'
sed -n '1,180p' playgrounds-ecosystem/scripts/check-nitro-type-resolution.mjs
echo
echo '--- canonical nitro-compat files ---'
cat -n packages/devtools/src/utils/nitro-compat.ts
echo
echo '--- devtools-kit ---'
cat -n packages/devtools-kit/src/_types/nitro-compat.ts
echo
echo '--- diff/stat summary ---'
git diff --stat
git diff -- playgrounds-ecosystem/scripts/check-nitro-type-resolution.mjs packages/devtools/src/utils/nitro-compat.ts packages/devtools-kit/src/_types/nitro-compat.ts | sed -n '1,260p'
echo
echo '--- find package manifests referencing deps/scripts ---'
rg -n '"(prepare|build|typecheck|test)"|"nitro(@|:|")|nitropack"|"nitro-compat"' package.json pnpm-workspace.yaml packages devtools playgrounds-ecosystem -S || trueRepository: nuxt/devtools
Length of output: 12973
Exercise the shipped Nitro compatibility declarations directly.
COMPAT duplicates the detection from @nuxt/devtools and @nuxt/devtools-kit; keep it generated from the same nitro-compat.ts sources so this script catches divergence in either package’s declaration, not just local textual diffs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@playgrounds-ecosystem/scripts/check-nitro-type-resolution.mjs` around lines
44 - 51, Update the COMPAT fixture generation in the script around the Nitro
compatibility declaration check to load and exercise the shipped nitro-compat.ts
declaration sources from both `@nuxt/devtools` and `@nuxt/devtools-kit`, rather than
maintaining a duplicated inline declaration. Ensure the script validates both
packages’ generated compatibility declarations so divergence is detected.
…k-only
The `dev` script on the sealed nuxt4/nuxt5 playgrounds fails ("JS heap out of
memory" on Nuxt 4, "socket hang up" on Nuxt 5) — but it's NOT a DevTools bug:
both reproduce with `@nuxt/devtools` removed from the `modules` array, i.e. the
sealed workspaces' base dev runtime is broken.
- Nuxt 4: `@nuxt/devtools`'s `vite@^8.1.5` peer + pnpm dedup pull Vite 8.1 into
the Nuxt 4.5.x app, whose dev SSR module runner targets an older Vite → the
first render hangs and the worker OOMs.
- Nuxt 5: the sealed workspace lacks the dependency-dedup `overrides` the root
`pnpm-workspace.yaml` uses to make the nuxt-nightly/Vite-8.1 dev runtime work,
so its dev SSR worker drops the render socket / OOMs. The root `playgrounds/`
(which share those overrides) run `dev` fine.
The production `nuxi build` path doesn't use the Vite dev module runner and is
unaffected, so these stay as **production build + typecheck** compatibility
checks (the intended "production playground" purpose): drop the `dev`/`generate`
/`preview` scripts, simplify the config + app, and document the dev limitation +
where to dogfood dev instead (root `playgrounds/empty` and `playgrounds/v4`).
Both playgrounds still pass `nuxi build` + `nuxi typecheck` on their respective
Nuxt major / Nitro engine.
… members so dev works Restores `dev` mode for both per-major DevTools playgrounds (the mode DevTools actually runs in), fixing the "JS heap out of memory" (Nuxt 4) / "socket hang up" (Nuxt 5) failures. Root cause (not a DevTools bug — both base apps render fine with DevTools disabled): the playgrounds were sealed workspaces pulling `@nuxt/devtools` via `link:../../packages/devtools`. A linked DevTools resolves its dependency tree from the ROOT node_modules while the sealed app has its OWN copies of Vite / `@vitejs/devtools`. With two instances, the app's dev SSR ends up transforming DevTools' whole dependency tree through a second Vite and the render worker blows its heap. Fix: make `nuxt4/` and `nuxt5/` members of the root pnpm workspace (added to the top-level `pnpm-workspace.yaml`; `modules/` stays sealed). `@nuxt/devtools` then resolves — via the root `overrides: '@nuxt/devtools': workspace:*` — out of the single root node_modules, so the app and DevTools share one Vite / `@vitejs/devtools` instance, exactly like the root `playgrounds/`. Scripts are `play:*`-prefixed (turbo-safe, matching `playgrounds/*`); deps come from the root catalog (`nuxt4` pins real `nuxt@^4.5.1`, `nuxt5` uses nuxt-nightly 5x). Verified: `play:dev` serves the app + embedded DevTools client (HTTP 200, no OOM/hang) on both; `play:build` + `play:typecheck` pass on both; the repo's own build/typecheck/lint/unit and the nitro type-resolution check still pass.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ecosystem-playground.yml (1)
22-23: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick winRemove the npm-based Corepack bootstrap.
pnpm/action-setup@v6runs before this step, so installing Corepack with npm is redundant and violates the repository’s package-manager policy. Rely on the existing pnpm 11.17.0 configuration instead.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ecosystem-playground.yml around lines 22 - 23, Remove the npm install -g corepack@latest bootstrap step from the workflow and retain reliance on the existing pnpm/action-setup@v6 configuration with pnpm 11.17.0. Keep corepack enable only if still required by the workflow after the redundant npm-based installation is removed.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@playgrounds-ecosystem/nuxt4/package.json`:
- Line 6: Update the play:dev scripts in
playgrounds-ecosystem/nuxt4/package.json (line 6) and
playgrounds-ecosystem/nuxt5/package.json (line 6) to bind to loopback by
default, while providing a separate explicit host override for container usage;
apply the same behavior in both files.
In `@playgrounds-ecosystem/nuxt5/package.json`:
- Around line 10-14: Update the nuxt5 playground dependency setup so
`@nuxt/devtools` resolves without relying on the root workspace’s workspace:*
installation. Add an explicit consumer dependency for `@nuxt/devtools`, or
remove/seal this playground from the root workspace if it is not intended to be
independently installable.
---
Outside diff comments:
In @.github/workflows/ecosystem-playground.yml:
- Around line 22-23: Remove the npm install -g corepack@latest bootstrap step
from the workflow and retain reliance on the existing pnpm/action-setup@v6
configuration with pnpm 11.17.0. Keep corepack enable only if still required by
the workflow after the redundant npm-based installation is removed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: dbaac184-beb1-42da-8d04-0ef98de18d14
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (10)
.github/workflows/ecosystem-playground.ymlplaygrounds-ecosystem/README.mdplaygrounds-ecosystem/REPORTS.mdplaygrounds-ecosystem/nuxt4/app.vueplaygrounds-ecosystem/nuxt4/nuxt.config.tsplaygrounds-ecosystem/nuxt4/package.jsonplaygrounds-ecosystem/nuxt5/app.vueplaygrounds-ecosystem/nuxt5/nuxt.config.tsplaygrounds-ecosystem/nuxt5/package.jsonpnpm-workspace.yaml
🚧 Files skipped from review as they are similar to previous changes (4)
- playgrounds-ecosystem/nuxt5/app.vue
- playgrounds-ecosystem/REPORTS.md
- playgrounds-ecosystem/README.md
- playgrounds-ecosystem/nuxt4/nuxt.config.ts
| "type": "module", | ||
| "private": true, | ||
| "scripts": { | ||
| "play:dev": "nuxi dev --host 0.0.0.0", |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not bind both playground dev servers to all interfaces by default.
Both play:dev scripts expose the development server and its DevTools/Nitro endpoints to any reachable network client. Keep loopback as the default and add a separate opt-in host override for container usage.
playgrounds-ecosystem/nuxt4/package.json#L6-L6: changeplay:devto use a loopback default or an explicit opt-in host.playgrounds-ecosystem/nuxt5/package.json#L6-L6: apply the same loopback-default or opt-in-host behavior.
📍 Affects 2 files
playgrounds-ecosystem/nuxt4/package.json#L6-L6(this comment)playgrounds-ecosystem/nuxt5/package.json#L6-L6
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@playgrounds-ecosystem/nuxt4/package.json` at line 6, Update the play:dev
scripts in playgrounds-ecosystem/nuxt4/package.json (line 6) and
playgrounds-ecosystem/nuxt5/package.json (line 6) to bind to loopback by
default, while providing a separate explicit host override for container usage;
apply the same behavior in both files.
…all DevTools from packed tarballs Reworks the per-major DevTools playgrounds to be sealed pnpm workspaces (their own `pnpm-workspace.yaml` + lockfile), installing this repo's `@nuxt/devtools` from packed tarballs instead of a root-workspace `workspace:*` — the same technique as vitejs/devtools' `playgrounds/production` (the real npm install path, from `dist`). `playgrounds-ecosystem/scripts/pack-local.mjs` builds the monorepo and `pnpm pack`s `@nuxt/devtools` + `@nuxt/devtools-kit` into `.tarballs/` (`pnpm pack` rewrites their `workspace:*` / `catalog:*` protocols into concrete versions). Each playground's `pnpm-workspace.yaml` points both packages at those tarballs via `overrides`, so everything installs into the playground's single `node_modules` — the app and DevTools share one Vite / `@vitejs/devtools` instance, which is what `nuxi dev` needs. This fixes the earlier `nuxi dev` failures (Nuxt 4 `JS heap out of memory`, Nuxt 5 `socket hang up`) without making the playgrounds root-workspace members: those came from a sealed workspace + `link:`, where the linked DevTools resolved its deps from the repo root while the app had its own Vite copy, so the dev SSR transformed DevTools' whole dep tree through a second Vite until the render worker died. `pnpm run setup` (build + pack + install) is the entry point; `play:dev` / `play:build` / `play:typecheck` run the app. Verified on both: `play:dev` serves the app + embedded DevTools client (HTTP 200, no OOM/hang), and `play:build` + `play:typecheck` pass. `.tarballs/` is gitignored (regenerated by setup); the sealed lockfiles are committed. Repo build/typecheck/lint/unit and the nitro single-engine type-resolution check still pass.
Follow-up to the sealed-tarball playgrounds, fixing the install error:
@nuxt/devtools is linked to .../playgrounds-ecosystem/nuxt4/node_modules
from .../packages/devtools
[ENOENT] ... open '.../playgrounds-ecosystem/.tarballs/nuxt-devtools.tgz'
Two changes make this robust, matching vitejs/devtools' production playground
more closely:
- Pack the DevTools tarballs into **each playground's own `.tarballs/`** and
reference them as `file:.tarballs/*.tgz` (was a shared `../.tarballs/` that
pointed *outside* the sealed workspace root — which let pnpm resolve in the
parent/root context and apply the repo-root `overrides: '@nuxt/devtools':
workspace:*'`, linking `packages/devtools` instead of the tarball).
- Override **both** `@nuxt/devtools` and `@nuxt/devtools-kit` to the tarballs
in each playground's `pnpm-workspace.yaml`, so the local override always wins
over any inherited root override.
`setup` remains the entry point (it packs the git-ignored tarballs, then
installs) — a bare `pnpm install` on a fresh checkout can't find the tarball
and is expected to fail; the README now calls this out explicitly.
Verified on both: `play:dev` serves the app + embedded DevTools client
(HTTP 200, no OOM / socket hang up), and `play:build` + `play:typecheck` pass.
…te-8.1 Both sides restructured the same regions of the ecosystem playground docs. Kept both intents: - README.md: this branch's directory-level layout (nuxt4/, nuxt5/, modules/, scripts/) with main's expanded module coverage folded into the `modules/` section — the Devtools-category set, its fixtures, the skip-list rationale, the full custom-tab id list, and the opt-in Playwright suite (now also a `tests/` row in the directory table). CI section covers both workflow jobs. - REPORTS.md: both sides appended to the same slot, so both survive — main's "Addendum 3" (Devtools-category findings), then this branch's "Nuxt 4 vs Nuxt 5" section. - ecosystem-playground.yml auto-merged, but left comments describing a `pnpm run prepare` stub that this branch had already replaced with a full `pnpm run build` (needed to pack the tarballs the sealed nuxt4/nuxt5 playgrounds install from). Rewrote those comments to match the steps. Verified: pnpm lint, pnpm typecheck, pnpm test:unit (67 tests) all pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Summary
Upgrades
nuxttonpm:nuxt-nightly@5xandviteto^8.1.5, removing theprior
~8.0.16pin. That pin existed only because@vitejs/devtools@0.4.2broke under Vite 8.1's reworked WebSocket-upgrade handling; against the
current
@vitejs/devtools@0.4.9the SSR e2e suite no longer reproduces thatcrash.
Nitro v3 compatibility
Nuxt 5 nightly's Nitro layer (
@nuxt/nitro-server-nightly) builds on thenext-gen Nitro v3 engine (package
nitro, notnitropack), which is abigger jump than a version bump — several DevTools internals depended on
Nitro v2-only APIs:
nitro.storageis gone. Nitro v3 no longer exposes a liveunstorageinstance on the Nitro object (storage mounts are now a build-time virtual
module consumed from inside the built server). The DevTools storage
browser (
server-rpc/storage.ts) now builds its ownunstorageinstancefrom
nitro.options.storage/devStorage, mirroring whatnitropackitself used to do internally. Without this, SSR prerendering crashed with
500s on every route.
server-routes/server-tasksused to watch Nitro's internalsrcstorage mount (also gone) to detect new route/task files; they now use
Nitro's
dev:reloadhook, which exists on both engines.data-inspector,module-main, andruntime/nitro/inlineare updatedfor the Nitro v2/v3 union types Nuxt 5's hooks now carry (
nitro:init,nitro:build:before,nitro:configcan all receive either engine).Other fixes along the way
unplugin-vue-markdown's Vite plugin needsprepend: truewhenregistered via
addVitePluginnow — Nuxt's non-isomorphic pluginwrapping hard-codes
enforce: 'post'otherwise, discarding the plugin'sown
enforce: 'pre'and breaking.mdSFC compilation in the DevToolsclient itself.
literal
nuxtpackage name;nuxt-nightly(and the oldernuxt-edgealias) are now recognized too, since aliased installs physically live
under a different
node_modulesname.vue-sfc-transformerto^0.1.17, matching what@nuxt/module-builder's bundledmkdistitself depends on —resolutionMode: highestotherwise hoists it to module-builder's ownnewer want, and mkdist's
.vuetransform silently breaks under thatmismatch (it was writing compiled output into
packages/devtools/src/runtime/**instead ofdist/, clobberingauth/index.htmlin the process).Known remaining issue (not blocking)
floating-vue's globally-registered<VDropdown>fails to render itsscoped-slot content under this stack — verified via a live e2e repro, not
present on
main(stable Nuxt 4). This is an upstream, already-openfloating-vue bug unrelated to how it's used here (Akryum/floating-vue#924,
#1085). Effect: component/composable/route names inside their dropdown
trigger don't render in the DevTools UI (the underlying list/count data is
correct). Filed as a follow-up rather than fixed here, since root-causing it
further is a floating-vue/Vue-core investigation, not a DevTools change.
Verification
pnpm build,pnpm typecheck,pnpm lint,pnpm test(lint + unit) allpass.
pnpm test:e2e:dev(emptyplayground) passes except for thefloating-vue issue above.
This upgrade was done with the help of an AI agent.