docs: plans for the next-major Vite DevTools / devframe integration (compat foundation + dock groups + terminals/messages + ecosystem)#1011
Conversation
Add self-contained implementation plans under plans/ for taking further advantage of Vite DevTools 0.4 / devframe 0.6 in Nuxt DevTools: - 01 — unify notifications on the devframe Messages system (retire the bespoke toast) - 02 — reuse the built-in Terminals dock via ctx.terminals (+ compat shim, opt-in PTY) - 03 — a "Nuxt" dock group with a general promote-tab-to-dock capability Each plan embeds the current-state file map, the devframe/Vite DevTools API references, decisions, step-by-step work, acceptance criteria and risks, so it can be executed independently as its own PR. README.md carries the shared context and recommended sequencing (01 -> 02 -> 03).
📝 WalkthroughWalkthroughAdds a documentation roadmap for integrating Nuxt DevTools with Vite DevTools 0.4 and devframe 0.6. It covers compatibility and deprecation diagnostics, unified Messages notifications, built-in Terminals reuse, Nuxt dock groups and promoted tools, and opt-in ecosystem playgrounds. Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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 `@plans/01-messages-unification.md`:
- Around line 120-145: The devframe-backed notification provider must be
registered before removing NNotification.vue. Move the provider registration
from NNotification.vue into the Nuxt DevTools client startup, such as app.vue
setup or a client plugin, using devtoolsUiProvideNotificationFn; keep
notification.ts as the UI-kit proxy and ensure existing callers still invoke the
concrete implementation after NNotification is removed.
In `@plans/02-terminals-reuse.md`:
- Around line 111-121: Update the terminal registration, write, and exit
handling described in the plan to retain per-session pending chunks and final
status when events arrive before kit connection or registration flush. Drain
queued output through the session controller and apply the queued stopped/error
status with the corresponding terminal update once registration completes,
preserving normal immediate behavior for already-registered sessions.
In `@plans/03-dock-groups-presentation.md`:
- Around line 152-156: Update the custom-tab refresh synchronization to track
registered dock entry IDs and compare them with the refreshed tab set. During
refresh, unregister or remove each previously registered ID that is no longer
present, while preserving registration and update behavior for existing tabs and
the queued flush behavior before devtoolsKit connects.
- Around line 139-158: The plan must define a server-visible registry for core
pages promoted via definePageMeta. Update the module-main/server-RPC design to
expose or share the promoted core tab metadata, including names, routes, titles,
and icons, so dock registration can discover Components, Server Routes, and
Pages independently of client-only state-tabs.ts; use this registry when
creating and synchronizing dock entries.
🪄 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
Run ID: ab5db00d-2feb-49dd-811a-5521cf561936
📒 Files selected for processing (4)
plans/01-messages-unification.mdplans/02-terminals-reuse.mdplans/03-dock-groups-presentation.mdplans/README.md
| ### Step 3 — client: re-point the ephemeral toast | ||
|
|
||
| - Reimplement `devtoolsUiShowNotification` (in | ||
| `packages/devtools-ui-kit/src/composables/notification.ts`) so that, instead of | ||
| driving the local `NNotification` component, it emits a devframe message via | ||
| the client RPC with `notify:true, autoDismiss:true, autoDelete:true` and a | ||
| `level` derived from intent (default `info`; allow callers to pass one). | ||
| - The UI kit must not hard-depend on the devtools client RPC. Keep the | ||
| `devtoolsUiProvideNotificationFn` seam: the **client** provides the concrete | ||
| implementation (which calls the devframe RPC) at startup; the UI kit stays a | ||
| thin proxy. So: keep `notification.ts` as the proxy, and register the | ||
| devframe-backed implementation from the Nuxt DevTools client (e.g. in | ||
| `packages/devtools/client/plugins/` or `app.vue` setup) via | ||
| `devtoolsUiProvideNotificationFn`. | ||
| - Map the existing callers' options (`message`, `icon`, `duration`, `position`) | ||
| onto message fields where they have an equivalent; `position`/`duration` become | ||
| no-ops or best-effort (the chrome toast owns placement/timing). Audit each | ||
| caller (`AssetDetails.vue`, `AssetDropZone.vue`, `editor.ts`, `timeline.vue`) | ||
| and keep the call sites unchanged in shape if possible. | ||
|
|
||
| ### Step 4 — retire the bespoke toast | ||
|
|
||
| - Remove `<NNotification />` from `packages/devtools/client/app.vue` and delete | ||
| (or empty) `packages/devtools-ui-kit/src/components/NNotification.vue` once no | ||
| caller renders it. If the UI kit exports `NNotification` publicly, keep an | ||
| export shim or do a deprecation cycle (see risks). |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Move the notification provider before removing NNotification.
The current provider registration lives in packages/devtools-ui-kit/src/components/NNotification.vue. Keeping notification.ts as a proxy is insufficient if that component is removed; registration of the devframe-backed provider must be an explicit prerequisite, or existing callers can become no-ops.
🧰 Tools
🪛 LanguageTool
[style] ~138-~138: This wording could be more concise.
Context: ...imeline.vue`) and keep the call sites unchanged in shape if possible. ### Step 4 — retire the b...
(ADJECTIVE_IN_ATTRIBUTE)
🤖 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 `@plans/01-messages-unification.md` around lines 120 - 145, The devframe-backed
notification provider must be registered before removing NNotification.vue. Move
the provider registration from NNotification.vue into the Nuxt DevTools client
startup, such as app.vue setup or a client plugin, using
devtoolsUiProvideNotificationFn; keep notification.ts as the UI-kit proxy and
ensure existing callers still invoke the concrete implementation after
NNotification is removed.
| - On `devtools:terminal:register`: create a `ReadableStream<string>` (keep its | ||
| controller in a `Map<id, controller>`), build a `DevframeTerminalSession` | ||
| `{ id, title: terminal.name, status: 'running', icon?, stream }`, and call | ||
| `devtoolsKit.terminals.register(session)`. Guard for `devtoolsKit` being | ||
| `undefined` before the kit connects — queue registrations and flush them in | ||
| `connectDevToolsKit` (mirror the existing `pendingBroadcasts` pattern in | ||
| `server-rpc/index.ts`). | ||
| - On `devtools:terminal:write`: `controller.enqueue(data)` for that id (and keep | ||
| a rolling buffer if the session's initial `buffer` needs seeding). | ||
| - On `devtools:terminal:exit`: `controller.close()`, set the session `status` to | ||
| `'stopped'`/`'error'` and `devtoolsKit.terminals.update(session)`. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Buffer writes and exits before kit connection.
Queueing only the registration is insufficient: devtools:terminal:write or devtools:terminal:exit can arrive before the session/controller is flushed, causing lost output or a session that never reaches its terminal state. Keep per-session pending chunks/status and drain them when registration completes.
🤖 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 `@plans/02-terminals-reuse.md` around lines 111 - 121, Update the terminal
registration, write, and exit handling described in the plan to retain
per-session pending chunks and final status when events arrive before kit
connection or registration flush. Drain queued output through the session
controller and apply the queued stopped/error status with the corresponding
terminal update once registration completes, preserving normal immediate
behavior for already-registered sessions.
| - Extend the tab meta contract with an opt-in `dock` flag: | ||
| - Core pages: read `dock` from `definePageMeta` (surface it through the tab | ||
| collection in `state-tabs.ts` / the client tab type). | ||
| - Custom tabs: add `dock?: boolean` to the custom-tab options type (the | ||
| `devtools:customTabs` contributions and `options.customTabs`), threaded | ||
| through `server-rpc/custom-tabs.ts` (`getCustomTabs`). | ||
| - Server side, in `module-main.ts`/`server-rpc`, collect the set of tabs with | ||
| `dock: true` and register a dock `iframe` entry per tab under `groupId:'nuxt'`, | ||
| choosing the URL per the **type-aware** rule in Decision 3: | ||
| - iframe custom tab → its own `src`. | ||
| - everything else → `/__nuxt_devtools__/client{route}?dock=1`. | ||
| - Use the tab's `icon`/`title` for the dock entry; derive a stable dock id | ||
| (e.g. `nuxt:tab:<name>`). | ||
| - Custom tabs arrive/refresh dynamically (`devtools:customTabs:refresh`) — keep | ||
| the promoted dock entries in sync (register on add, update on change; use the | ||
| `ctx.docks.register(...)` return `{ update }` handle, and re-evaluate on | ||
| refresh). Guard for `devtoolsKit` not yet connected (queue + flush, mirroring | ||
| `server-rpc/index.ts` `pendingBroadcasts`). | ||
| - Ship the curated default: mark **Components, Server Routes, Pages** with | ||
| `dock: true` in their `definePageMeta`. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Provide a server-visible registry for promoted core pages.
definePageMeta and state-tabs.ts are client-side sources, but dock entries are registered from module-main.ts/server RPC. The plan does not define how the server discovers Components, Server Routes, and Pages; without a shared manifest or explicit server registry, the default promoted entries will never be registered.
🤖 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 `@plans/03-dock-groups-presentation.md` around lines 139 - 158, The plan must
define a server-visible registry for core pages promoted via definePageMeta.
Update the module-main/server-RPC design to expose or share the promoted core
tab metadata, including names, routes, titles, and icons, so dock registration
can discover Components, Server Routes, and Pages independently of client-only
state-tabs.ts; use this registry when creating and synchronizing dock entries.
| - Custom tabs arrive/refresh dynamically (`devtools:customTabs:refresh`) — keep | ||
| the promoted dock entries in sync (register on add, update on change; use the | ||
| `ctx.docks.register(...)` return `{ update }` handle, and re-evaluate on | ||
| refresh). Guard for `devtoolsKit` not yet connected (queue + flush, mirroring | ||
| `server-rpc/index.ts` `pendingBroadcasts`). |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Remove stale dock entries on custom-tab deletion.
The implementation describes registering and updating promoted tabs, but not unregistering entries when devtools:customTabs:refresh removes a tab. Track the registered IDs and remove any no longer present during refresh; otherwise deleted custom tabs remain visible in the Nuxt dock group.
🤖 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 `@plans/03-dock-groups-presentation.md` around lines 152 - 156, Update the
custom-tab refresh synchronization to track registered dock entry IDs and
compare them with the refreshed tab set. During refresh, unregister or remove
each previously registered ID that is no longer present, while preserving
registration and update behavior for existing tabs and the queued flush behavior
before devtoolsKit connects.
Reframe the plan set around the major-version strategy: keep the existing Nuxt DevTools API, expose devframe-native APIs alongside it, and soft-deprecate via nostics-driven diagnostics + shims (shim-first; break only where a faithful shim is infeasible), then build the feature work on top. - 00-compat-foundation.md: connect-safe devframe host accessors on nuxt.devtools (docks/terminals/messages/commands/diagnostics); a Nuxt nostics deprecation catalog (console reporter + registered into the DevTools host); shim-first policy + a per-API deprecation classification map + pilot deprecations. - 04-ecosystem-playgrounds.md: playgrounds-ecosystem/ per popular module (og-image/SEO, scripts, content, tailwindcss, nuxthub, fonts, image) linked to the local devtools, opt-in install (out of main CI), with per-module compat reports that seed upstream migration issues/PRs. - README + 01/02/03: sequence 00 first, cross-link plans to the foundation's connect-safe hosts and deprecation catalog.
antfubot
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
plans/00-compat-foundation.md (1)
132-136: 🩺 Stability & Availability | 🔵 TrivialEnsure synchronous stubs handle pre-connect cancellations.
When buffering mutating calls that return a handle or an ID (such as terminal or subprocess handles), ensure that the proxy returns a stable, synchronous stub immediately. If the caller interacts with this stub pre-connect (e.g., calling
.terminate()or unregistering), the queue must process this correctly—such as dropping the pending creation entirely—to avoid zombie processes or resource leaks once the queue flushes.🤖 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 `@plans/00-compat-foundation.md` around lines 132 - 136, Update the buffered proxy wrappers described for devtoolsKitCtx so mutating calls that return handles or IDs immediately return stable synchronous stubs before connection. Track pre-connect interactions such as terminate or unregister, and have connectDevToolsKit skip or cancel the corresponding queued creation so canceled resources are never started.
🤖 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 `@plans/00-compat-foundation.md`:
- Around line 99-103: Update the deprecation-warning references in
plans/00-compat-foundation.md by removing the outdated “~lines 165‑168” locator
from the packages/devtools/src/server-rpc/index.ts disableAuthorization notice,
while preserving the referenced symbols and surrounding guidance.
---
Nitpick comments:
In `@plans/00-compat-foundation.md`:
- Around line 132-136: Update the buffered proxy wrappers described for
devtoolsKitCtx so mutating calls that return handles or IDs immediately return
stable synchronous stubs before connection. Track pre-connect interactions such
as terminate or unregister, and have connectDevToolsKit skip or cancel the
corresponding queued creation so canceled resources are never started.
🪄 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
Run ID: 53e9fa0c-8b32-4dd7-b48f-0c0287e74415
📒 Files selected for processing (6)
plans/00-compat-foundation.mdplans/01-messages-unification.mdplans/02-terminals-reuse.mdplans/03-dock-groups-presentation.mdplans/04-ecosystem-playgrounds.mdplans/README.md
🚧 Files skipped from review as they are similar to previous changes (3)
- plans/01-messages-unification.md
- plans/02-terminals-reuse.md
- plans/03-dock-groups-presentation.md
| Existing ad-hoc deprecation warnings to fold into this: the `startSubprocess` | ||
| `getProcess()` `console.warn` (`packages/devtools-kit/src/index.ts` ~line 126) | ||
| and the `logger.warn` in `packages/devtools/src/server-rpc/index.ts` (the | ||
| `disableAuthorization` notice, ~lines 165‑168), and the `disableAuthorization` | ||
| warning in `module-main.ts`. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Correct the line reference for the disableAuthorization notice.
The reference to ~lines 165‑168 in packages/devtools/src/server-rpc/index.ts appears to be outdated. Based on the provided context snippet, lines 165-168 currently contain the error handling block for extended RPC registrations, not the disableAuthorization notice. Removing the specific line numbers will prevent confusion and future drift.
📝 Proposed fix to remove specific line numbers
-`disableAuthorization` notice, ~lines 165‑168), and the `disableAuthorization`
+`disableAuthorization` notice), and the `disableAuthorization`📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Existing ad-hoc deprecation warnings to fold into this: the `startSubprocess` | |
| `getProcess()` `console.warn` (`packages/devtools-kit/src/index.ts` ~line 126) | |
| and the `logger.warn` in `packages/devtools/src/server-rpc/index.ts` (the | |
| `disableAuthorization` notice, ~lines 165‑168), and the `disableAuthorization` | |
| warning in `module-main.ts`. | |
| Existing ad-hoc deprecation warnings to fold into this: the `startSubprocess` | |
| `getProcess()` `console.warn` (`packages/devtools-kit/src/index.ts` ~line 126) | |
| and the `logger.warn` in `packages/devtools/src/server-rpc/index.ts` (the | |
| `disableAuthorization` notice), and the `disableAuthorization` | |
| warning in `module-main.ts`. |
🤖 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 `@plans/00-compat-foundation.md` around lines 99 - 103, Update the
deprecation-warning references in plans/00-compat-foundation.md by removing the
outdated “~lines 165‑168” locator from the
packages/devtools/src/server-rpc/index.ts disableAuthorization notice, while
preserving the referenced symbols and surrounding guidance.
…ck-groups # Conflicts: # plans/README.md
There was a problem hiding this comment.
🧹 Nitpick comments (2)
plans/vite-devtools-integration/04-ecosystem-playgrounds.md (2)
57-62: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReplace custom workspace filename with a nested workspace boundary.
pnpmnatively reads onlypnpm-workspace.yamland does not support custom workspace filenames likepnpm-workspace.ecosystem.yamlwithout the use of fragile wrapper scripts to copy or rename files.To effectively isolate the ecosystem dependencies from the main repository install while still allowing contributors to install them all at once, place a standard
pnpm-workspace.yamldirectly inside theplaygrounds-ecosystem/directory. This acts as a native workspace boundary that preventspnpmfrom traversing up to the root workspace. Contributors can then cleanly install all playgrounds into a single isolated lockfile usingpnpm -C playgrounds-ecosystem install.♻️ Proposed refactor
Options, pick one: - - **Separate opt-in workspace file / script** that installs the ecosystem set - on demand (e.g. a `pnpm -C playgrounds-ecosystem/<module> install` per - playground, each with its own lockfile), or - - a dedicated `pnpm-workspace.ecosystem.yaml` + an npm script - (`pnpm run ecosystem:install`) that a contributor runs explicitly. + - **Nested workspace boundary** (recommended): Place a standalone `pnpm-workspace.yaml` directly inside `playgrounds-ecosystem/` (e.g., `packages: ['*']`). Contributors run `pnpm -C playgrounds-ecosystem install` to install all playgrounds into a single isolated lockfile. + - **Fully independent per playground**: No workspace file at all; run `pnpm -C playgrounds-ecosystem/<module> install` to generate a separate lockfile per module.🤖 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 `@plans/vite-devtools-integration/04-ecosystem-playgrounds.md` around lines 57 - 62, Update the ecosystem installation options in plans/vite-devtools-integration/04-ecosystem-playgrounds.md to remove the custom pnpm-workspace.ecosystem.yaml approach. Specify a standard pnpm-workspace.yaml inside playgrounds-ecosystem/ and direct contributors to run pnpm -C playgrounds-ecosystem install, preserving the isolated workspace and lockfile behavior.
63-67: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConfirming identical directory depth for local devtools resolution.
Both
playgrounds/<name>/andplaygrounds-ecosystem/<module>/are exactly two directory levels down from the repository root. Therefore,'../../local'will resolve identically to the repository-rootlocal/directory without requiring any path adjustments. The prompts to verify this depth can be removed to reduce ambiguity for the implementer.
plans/vite-devtools-integration/04-ecosystem-playgrounds.md#L63-L67: Update to assert the identical depth and exact resolution behavior.plans/vite-devtools-integration/04-ecosystem-playgrounds.md#L125-L127: Update the bullet to state that the path resolves exactly as it does inplaygrounds/*.♻️ Proposed refactor
For lines 63-67:
- - Each playground links the local devtools. Confirm how `playgrounds/*` resolve - `'../../local'` (the repo exposes a `local` Nuxt module entry for the built - `@nuxt/devtools`); replicate that resolution from the deeper - `playgrounds-ecosystem/<module>/` path (likely `'../../local'` still resolves - to `<repo>/local` — verify the depth). + - Each playground links the local devtools. `playgrounds/*` resolves the built module via + `'../../local'`. Replicate this resolution exactly from + `playgrounds-ecosystem/<module>/` (as both paths are exactly two levels deep from the repository root, `'../../local'` resolves identically).For lines 125-127:
- - **Local-devtools resolution.** Verify the `'../../local'` link resolves from - the extra directory depth; adjust the relative path if - `playgrounds-ecosystem/<module>/` is one level deeper than `playgrounds/<name>/`. + - **Local-devtools resolution.** The `'../../local'` link resolves exactly as it does in `playgrounds/*`, as both structures are exactly two levels deep from the repository root.🤖 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 `@plans/vite-devtools-integration/04-ecosystem-playgrounds.md` around lines 63 - 67, Update plans/vite-devtools-integration/04-ecosystem-playgrounds.md at lines 63-67 to assert that playgrounds/<name>/ and playgrounds-ecosystem/<module>/ are both two levels below the repository root, so '../../local' resolves to the same repository-root local/ directory without adjustment. Update lines 125-127 to state that this path resolves exactly as it does in playgrounds/*, removing the verification prompts.
🤖 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.
Nitpick comments:
In `@plans/vite-devtools-integration/04-ecosystem-playgrounds.md`:
- Around line 57-62: Update the ecosystem installation options in
plans/vite-devtools-integration/04-ecosystem-playgrounds.md to remove the custom
pnpm-workspace.ecosystem.yaml approach. Specify a standard pnpm-workspace.yaml
inside playgrounds-ecosystem/ and direct contributors to run pnpm -C
playgrounds-ecosystem install, preserving the isolated workspace and lockfile
behavior.
- Around line 63-67: Update
plans/vite-devtools-integration/04-ecosystem-playgrounds.md at lines 63-67 to
assert that playgrounds/<name>/ and playgrounds-ecosystem/<module>/ are both two
levels below the repository root, so '../../local' resolves to the same
repository-root local/ directory without adjustment. Update lines 125-127 to
state that this path resolves exactly as it does in playgrounds/*, removing the
verification prompts.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 13b66387-4b04-4ba3-a6f8-f7435dcc85c0
📒 Files selected for processing (7)
plans/README.mdplans/vite-devtools-integration/00-compat-foundation.mdplans/vite-devtools-integration/01-messages-unification.mdplans/vite-devtools-integration/02-terminals-reuse.mdplans/vite-devtools-integration/03-dock-groups-presentation.mdplans/vite-devtools-integration/04-ecosystem-playgrounds.mdplans/vite-devtools-integration/README.md
2 participants
What
Adds self-contained implementation plans under
plans/for the next major of Nuxt DevTools on top of Vite DevTools 0.4 / devframe 0.6 (migration already landed, #1010). Planning/RFC PR — no product code changes.Strategy (this major)
Breaking changes are acceptable, but migration must be minimal + self-discoverable, with a gradual long-term move to devframe-native APIs:
nuxt.devtools).fix+ doc link). Hard-break only where a faithful shim is infeasible.Workstreams
00-compat-foundation.mdnuxt.devtools; nostics-driven soft-deprecation (catalog + registered into the DevTools host); shim-first policy + deprecation map + pilots.01-messages-unification.md02-terminals-reuse.md@xtermterminals; use the built-in Terminals dock viactx.terminals; compat shim fordevtools:terminal:register; opt-in PTY.03-dock-groups-presentation.md04-ecosystem-playgrounds.mdplaygrounds-ecosystem/per popular module (og-image/SEO, scripts, content, tailwindcss, nuxthub, fonts, image), linked to local devtools, opt-in install, per-module compat report.Recommended order 00 → 01 → 02 → 03, with 04 running alongside as the dogfooding surface. Each plan is independently executable (embeds current-state file maps, API refs, decisions, steps, acceptance criteria, risks) and is intended to be built/reviewed as its own follow-up PR.
plans/README.mdholds shared context + the locked decisions (sharpened in a design session).Why
Nuxt DevTools currently duplicates platform features (monolithic iframe, its own
@xtermterminals, its own client-only toast). These plans move it to use devframe's built-in Terminals/Messages docks and the dock-group feature behind a compatibility layer, improving discoverability, cutting maintained surface, aligning behavior, and unlocking capabilities (interactive PTY, a persistent leveled message center) — while keeping module-author migration minimal via shims + nostics diagnostics.This PR was created with the help of an agent.