fix(dock): use the dockview package, not dockview-core (closes #60) #64

Merged

lz merged 1 commit from fix/dockview-package into main

2026-07-13 21:11:42 +02:00

lz commented

2026-07-13 11:08:03 +02:00

Owner

Closes #60. Targets feat/dockview-pr-c2 (#63), the tip of the dockview stack.

The warning was not cosmetic

#60 filed this as "low priority, cosmetic". It isn't. The console notice —

dockview: do not use "dockview-core" directly — it is an internal package.

— was telling us we were missing functionality, not breaching etiquette.

I probed the published tarball rather than the docs, as the issue itself instructed. dockview's entry point does three things:

__exportStar(require("dockview-core"), exports);   // re-export everything
registerModules(Modules);                          // ← the actual point
markDockviewPackageLoaded();                       // ← merely silences the warning

And Modules is:

const Modules = [
    TabGroupChipsModule,
    ContextMenuModule,
    AdvancedDnDModule,
    AccessibilityModule,
];

On dockview-core alone those services are simply absent. The dock has been shipping with no keyboard accessibility and no context menu at all.

Is `dockview` still the React wrapper? No.

That was the issue's central worry, and the reason dockview-core was chosen in #58. Verified against the published tarball, not the docs:

dependencies: { "dockview-core": "^7.0.2" } — nothing else
peerDependencies: none
No react import anywhere in the shipped bundle (main.esm.mjs / main.cjs.js)
Its type entry is literally export * from 'dockview-core';

So it is a strict superset: same API surface, zero new runtime dependencies, plus the feature modules. The original reasoning in #58 was sound at the time; upstream simply repositioned the packages.

Registering the modules is necessary but NOT sufficient

This is the part that would have been easy to get wrong. Both features are opt-in. Swapping the import makes the warning disappear while shipping exactly as little accessibility as before — a fix that looks complete and does nothing.

So the options are enabled explicitly:

keyboardNavigation: true,
getTabContextMenuItems: () => ['close', 'closeOthers', 'closeAll']

keyboardNavigation — Ctrl+Shift+Arrows moves focus to the adjacent group; Ctrl+M arms a two-phase keyboard dock (pick target → pick edge) with a live drop preview and screen-reader narration. Before this, the layout could only be rearranged with a mouse.
getTabContextMenuItems — right-click a tab for Close / Close Others / Close All. This matters more than it looks: PR-C2 removed the "reset layout" button because panels became individually closable, which left no way to clear a mangled grid in one go. This is that escape hatch, and it comes from upstream rather than from us.

Verification

pnpm typecheck → 0 errors (4763 files). pnpm test → 643 passing (71 files). Build clean.

Browser, on the seeded throwaway instance:

check	result
`dockview-core` internal-package warning	gone
Product console errors / warnings	0 (only headless-Chromium WebGL GPU notices from xterm's renderer)
Dock still works	tabs, per-session colours, close buttons, identity rings — all intact
Right-click a tab	Close / Close Others / Close All — proof the modules are registered, since `ContextMenuModule` ships only in `dockview`
`aria-live` region	present, narrating panel changes (`"terminal opened"`)
Tab ARIA	`role="tab"`, `aria-selected`

Honestly not verified

I could not exercise Ctrl+M keyboard docking in headless Chromium — the chord never reached the handler, and I'm not willing to claim it works on the strength of the option being set. What is proven is that the modules are registered and active (the context menu cannot exist otherwise) and that the option typechecks against DockviewComponentOptions.

Worth thirty seconds in a real browser: focus a tab, press Ctrl+M, arrows, Enter.

This is also relevant to the arc's other open gap — touch drag on real hardware is still unverified, and AdvancedDnDModule is exactly the module that was missing. It may well improve matters, but I have not demonstrated that either.

Closes #60. **Targets `feat/dockview-pr-c2` (#63)**, the tip of the dockview stack. ## The warning was not cosmetic #60 filed this as "low priority, cosmetic". It isn't. The console notice — > `dockview: do not use "dockview-core" directly — it is an internal package.` — was telling us we were **missing functionality**, not breaching etiquette. I probed the published tarball rather than the docs, as the issue itself instructed. `dockview`'s entry point does three things: ```js __exportStar(require("dockview-core"), exports); // re-export everything registerModules(Modules); // ← the actual point markDockviewPackageLoaded(); // ← merely silences the warning ``` And `Modules` is: ```js const Modules = [ TabGroupChipsModule, ContextMenuModule, AdvancedDnDModule, AccessibilityModule, ]; ``` On `dockview-core` alone those services are simply **absent**. The dock has been shipping with **no keyboard accessibility and no context menu at all**. ## Is `dockview` still the React wrapper? No. That was the issue's central worry, and the reason `dockview-core` was chosen in #58. Verified against the published tarball, not the docs: - `dependencies`: `{ "dockview-core": "^7.0.2" }` — nothing else - `peerDependencies`: **none** - No `react` import anywhere in the shipped bundle (`main.esm.mjs` / `main.cjs.js`) - Its type entry is literally `export * from 'dockview-core';` So it is a strict superset: same API surface, zero new runtime dependencies, plus the feature modules. The original reasoning in #58 was sound at the time; upstream simply repositioned the packages. ## Registering the modules is necessary but NOT sufficient This is the part that would have been easy to get wrong. **Both features are opt-in.** Swapping the import makes the warning disappear while shipping exactly as little accessibility as before — a fix that looks complete and does nothing. So the options are enabled explicitly: ```ts keyboardNavigation: true, getTabContextMenuItems: () => ['close', 'closeOthers', 'closeAll'] ``` - **`keyboardNavigation`** — `Ctrl+Shift+Arrows` moves focus to the adjacent group; `Ctrl+M` arms a two-phase keyboard dock (pick target → pick edge) with a live drop preview and screen-reader narration. Before this, the layout could only be rearranged with a mouse. - **`getTabContextMenuItems`** — right-click a tab for **Close / Close Others / Close All**. This matters more than it looks: PR-C2 removed the "reset layout" button *because* panels became individually closable, which left no way to clear a mangled grid in one go. This is that escape hatch, and it comes from upstream rather than from us. ## Verification `pnpm typecheck` → 0 errors (4763 files). `pnpm test` → 643 passing (71 files). Build clean. Browser, on the seeded throwaway instance: | check | result | |---|---| | `dockview-core` internal-package warning | **gone** | | Product console errors / warnings | **0** (only headless-Chromium WebGL GPU notices from xterm's renderer) | | Dock still works | tabs, per-session colours, close buttons, identity rings — all intact | | **Right-click a tab** | **Close / Close Others / Close All** — proof the modules are registered, since `ContextMenuModule` ships only in `dockview` | | `aria-live` region | present, narrating panel changes (`"terminal opened"`) | | Tab ARIA | `role="tab"`, `aria-selected` | ## Honestly not verified **I could not exercise `Ctrl+M` keyboard docking in headless Chromium** — the chord never reached the handler, and I'm not willing to claim it works on the strength of the option being set. What *is* proven is that the modules are registered and active (the context menu cannot exist otherwise) and that the option typechecks against `DockviewComponentOptions`. Worth thirty seconds in a real browser: focus a tab, press `Ctrl+M`, arrows, `Enter`. This is also relevant to the arc's other open gap — **touch drag on real hardware** is still unverified, and `AdvancedDnDModule` is exactly the module that was missing. It may well improve matters, but I have not demonstrated that either.

lz added 1 commit

2026-07-13 11:08:03 +02:00

fix(dock): use the dockview package, not dockview-core (closes #60 )

ci / nexus (pull_request) Successful in 4m13s

Details

ci / images (pull_request) Successful in 6m34s

Details

pr-image-cleanup / delete-pr-images (pull_request) Successful in 6s

Details

b3cdaf1f7c

The console warning was not etiquette — it was telling us we were missing
functionality.

`dockview` is no longer a React wrapper (verified against the published tarball:
no react in dependencies, peerDependencies, or the shipped bundle; its type entry
is literally `export * from 'dockview-core'`). It is the core PLUS four feature
modules it registers on load: Accessibility, AdvancedDnD, ContextMenu and
TabGroupChips. On dockview-core alone those services are simply absent, so the
dock shipped with no keyboard accessibility and no context menu at all.

Registering the modules is necessary but NOT sufficient — both features are
opt-in, so the easy version of this fix (swap the import, warning goes away)
would have shipped exactly as little accessibility as before. Hence:

  keyboardNavigation: true
      Ctrl+Shift+Arrows  focus the adjacent group
      Ctrl+M             two-phase keyboard docking, with a live drop preview
                         and screen-reader narration

  getTabContextMenuItems: () => ['close', 'closeOthers', 'closeAll']
      PR-C2 removed the 'reset layout' button because panels became individually
      closable, which left no way to clear a mangled grid in one go. This is that
      escape hatch, and it comes from upstream rather than from us.

lz changed target branch from feat/dockview-pr-c2 to main

2026-07-13 21:11:08 +02:00

lz merged commit f6c8cee20d into main

2026-07-13 21:11:42 +02:00

lz deleted branch fix/dockview-package

2026-07-13 21:11:42 +02:00

lz referenced this pull request from a commit

2026-07-13 21:11:42 +02:00

Merge pull request 'fix(dock): use the dockview package, not dockview-core (closes #60)' (#64) from fix/dockview-package into main