feat(kit,core): plugin-declared dock ordering, layout, and window defaults

[dvcolomban]

Summary

Vite plugins had no way to control dock-bar category order, float-mode capacity, or first-run window placement — category order was decided solely by the upstream DEFAULT_CATEGORIES_ORDER table, the float bar's inline-item cap was a fixed constant, and the injected overlay always started in float mode at a fixed position.

• DevToolsPluginOptions.dock (DevToolsDockConfig): a plugin declares categoryOrder, maxVisibleItems, defaultMode, defaultPosition alongside its setup(). Collected across every plugin during the Vite plugin scan (last plugin wins per scalar key, categoryOrder shallow-merges), stashed on ViteDevToolsNodeContext.dockConfig, and handed to every client once via ConnectionMeta.dockConfig — riding the connection handshake every client already does, since the value is fixed for the life of the dev server. No new shared-state channel.
• New docksCategoriesOrder user setting: category headers in the Settings dock panel are now drag-and-droppable, reusing the same machinery entry rows already use (drag detection, self-healing reset-to-default). The outer bar's sort pre-merges the plugin's categoryOrder beneath the user's own drag order into the categoryOrderOverride slot docksGroupByCategories already had for a group's own ordering — no new parameters needed on that function.
• Dock.vue folds a declared maxVisibleItems into the resolved float layout (an explicit layout prop still wins); resolveDockLayout clamps it to >= 1. Edge mode is unaffected by design — it shows every entry with no capacity cutoff.
• The injected overlay seeds its vite-devtools-dock-state localStorage defaults (mode/position) from a declared defaultMode/defaultPosition — only for a developer with no stored preference yet; it never overwrites one who already moved their dock.

Verification

• pnpm lint && pnpm typecheck && pnpm test all pass (full vitest suite, including an updated tsnapi snapshot for the new public exports).
• Manually validated end-to-end in the core playground: 5 declared categories × 3 docks each, with a deliberately non-alphabetical categoryOrder and reversed in-category defaultOrder — confirmed correct rendering in an isolated browser profile (bar order matches declared weights exactly; in-category order matches defaultOrder; maxVisibleItems: 10 caps float mode at exactly 10 inline items + overflow; edge mode shows everything uncapped; defaultMode: 'edge'/defaultPosition: 'left' seeds correctly on a fresh profile).
• Category drag-and-drop and its reset affordance verified in Settings → Docks.

Screenshots

Captured in the core playground with a plugin declaring
dock: { categoryOrder: { web: -60, advanced: -50, app: -40 }, maxVisibleItems: 4 }.

maxVisibleItems: 4 — 4 inline items, the rest behind the overflow button	Settings → Docks — draggable category headers	Category dragged to the top, with its reset affordance

[pkg-pr-new]

Open in StackBlitz

@vitejs/devtools

npm i https://pkg.pr.new/@vitejs/devtools@515

@vitejs/devtools-kit

npm i https://pkg.pr.new/@vitejs/devtools-kit@515

@vitejs/devtools-oxc

npm i https://pkg.pr.new/@vitejs/devtools-oxc@515

@vitejs/devtools-rolldown

npm i https://pkg.pr.new/@vitejs/devtools-rolldown@515

@vitejs/devtools-vite

npm i https://pkg.pr.new/@vitejs/devtools-vite@515

@vitejs/devtools-vitest

npm i https://pkg.pr.new/@vitejs/devtools-vitest@515

commit: f128ced

[antfu]

Instead of putting it into the connectionMeta, maybe we could have it in sharedState?

[dvcolomban]

I did explored moving it to a share state (see this commit), and it is semantically cleaner as dock config aren't really connections metas.

However it does mean threading a lot more plumbing 🤔

Not sure if it's a cleaner design, or if it is over-engineering.

Maybe dock default state are not worth the increase in complexity ?