finding(plugin-charts): two deep subpaths resolve only through the repo vitest alias — the #4325 shape again, and this one has a value import

[yinlianghui]

Observation-class finding, surfaced while wiring @object-ui/plugin-dashboard's tests into tsc for #4040 (closing tranche). Nothing a user meets today — both live consumers are tests, and they pass.

This is the same class as #4325 (@object-ui/fields deep subpaths), one package over. It is filed separately rather than as a comment there because #4325 is closed, and because the resolution that closed it does not transfer cleanly — see "Why the #4325 remedy does not just apply" below.

What

packages/plugin-charts/package.json publishes exactly one entry point:

"exports": {
  ".": { "types": "./dist/index.d.ts", "import": "./dist/index.js", "require": "./dist/index.umd.cjs" }
}

Two plugin-dashboard tests import subpaths of it:

packages/plugin-dashboard/src/__tests__/DatasetWidget.chartConfig.dom.test.tsx:38
    import '@object-ui/plugin-charts/AdvancedChartImpl';
packages/plugin-dashboard/src/__tests__/DatasetWidget.comboPresentation.test.tsx:52
    import { normalizeChartSchema } from '@object-ui/plugin-charts/normalizeChartSchema';

Both resolve only because vitest.config.mts:262 aliases the whole package name to its source directory:

'@object-ui/plugin-charts': path.resolve(__dirname, './packages/plugin-charts/src')

Neither name is exported from the barrel either — packages/plugin-charts/src/index.tsx exports ChartBarRenderer, ChartRenderer, ObjectChart, ObjectChartBlock, chartComponents and the BarChartSchema type, and nothing else. Under Node's own resolution, or from any consumer outside this repo's vitest config, both specifiers are ERR_PACKAGE_PATH_NOT_EXPORTED.

How it surfaced

Type-checking plugin-dashboard's tests puts both files in front of tsc, which asks the same question Node would:

src/__tests__/DatasetWidget.chartConfig.dom.test.tsx(38,8): error TS2882: Cannot find module or type declarations for side-effect import of '@object-ui/plugin-charts/AdvancedChartImpl'.
src/__tests__/DatasetWidget.comboPresentation.test.tsx(52,38): error TS2307: Cannot find module '@object-ui/plugin-charts/normalizeChartSchema' or its corresponding type declarations.

These were 2 of the 14 errors that package's tests carried.

Why the #4325 remedy does not just apply

#4325 was closed by PR #4460, "drop the unpublished deep subpath" — the test's anti-race guarantee was rebuilt on a witness that did not need it. That answer fits the FIRST import here and not the second:

• AdvancedChartImpl is a side-effect import. Its job is to pre-load, at module scope, the chunk ChartRenderer reaches through React.lazy, so the unbounded first import is paid in the import phase instead of inside RTL's 1000 ms waitFor. Structurally identical to @object-ui/fields deep subpaths resolve only through the repo vitest alias — its exports map publishes none of them #4325's MarkdownContent case, so test(plugin-detail): drop the unpublished @object-ui/fields deep subpath (#4325) #4460's approach plausibly transfers.
• normalizeChartSchema is a value import, and the assertions run the widget's emitted schema through it. That is the whole point of the file: what it pins is what AdvancedChartImpl actually receives, rather than a restatement of the renderer's translation layer. Dropping the import does not relocate the guarantee — it deletes it and replaces the test with a copy of the thing under test. So "drop the subpath" is not available here without a different witness that does not exist yet.

What the #4040 PR did, and why it is not the answer

PR for #4040's closing tranche keeps both imports and restates the vitest alias as one narrow paths entry in the new packages/plugin-dashboard/tsconfig.test.json:

"paths": { "@object-ui/plugin-charts/*": ["packages/plugin-charts/src/*"] }

That points tsc at the very files vitest loads, so the compiler checks the real modules rather than a hand-written shim, and no test semantics changed. It is commented in that file as a workaround for this gap, with the instruction to delete it once the gap is closed either way. It is worth recording precisely because that config now carries a source-tree path every other wired-up package avoided on purpose — the same debt #4325 recorded, with the same wording, before its ruling removed it.

Why it is finding and not queued

No user-visible behaviour depends on it, and the fix is a product call about what @object-ui/plugin-charts publishes, not a code one:

• The subpaths are intended — a renderer's normalization layer is a reasonable thing to test against directly. Then plugin-charts should publish them in its exports map with the matching dist layout, and the paths entry goes away.
• They are not intended — the package's surface is its index. Then normalizeChartSchema needs to be re-exported from the barrel (a one-line surface decision) or the test needs a different witness, and the lazy-chunk pre-load needs test(plugin-detail): drop the unpublished @object-ui/fields deep subpath (#4325) #4460's treatment.

Note the second bullet is not symmetrical with #4325: there, "not intended" meant the import could simply go. Here it still requires a decision about normalizeChartSchema's reachability, because the test cannot make its assertion without the real translation layer.

A general question worth asking once instead of per-package: this is the second instance in two tranches, and the vitest alias makes the mistake invisible until a package's tests reach tsc. Now that #4040 has every package type-checking its tests, a gate over exports maps versus the deep specifiers actually imported would catch the third one at authoring time.

Refs #4325, #4460, #4040.

---

Generated by Claude Code

[yinlianghui]

CLAIM — session_017Qqyix2QcnpUC9XeYVDzx3, branch claude/issue-4529-charts-subpath-contract. Dispatching a dev agent now.

PM ruling (delegated decision authority; maintainer veto window open — record objections here): the two imports get two separate dispositions, each measured, because they are different kinds of dependency:

1. normalizeChartSchema (value import, load-bearing witness): first measure whether it is already reachable from plugin-charts' ROOT entry. If not, it is a genuine cross-package contract — plugin-dashboard's tests run emitted schemas through the same normalization the charts runtime applies, which is exactly what a consumer does — so export it from the package root entry (the door), not a new subpath (subpath proliferation is its own smell). Grade plugin-charts MINOR (entry-reachable additive growth). Only fall back to a subpath export if measurement shows the root entry deliberately excludes it (e.g. a lazy-loading/bundle-size constraint with an established repo pattern) — and say so.
2. AdvancedChartImpl (side-effect import, registration): the @object-ui/fields deep subpaths resolve only through the repo vitest alias — its exports map publishes none of them #4325 precedent (PR test(plugin-detail): drop the unpublished @object-ui/fields deep subpath (#4325) #4460 dropped the unpublished deep subpath) transfers HERE — measure how production code loads AdvancedChartImpl (likely lazy/dynamic) and make the test reach the registration the same published way production does. Do not add a subpath export just to keep an eager deep import alive.
3. Then delete the transitional paths entry from packages/plugin-dashboard/tsconfig.test.json (PR chore(types): plugin-dashboard's tests compile — the #4040 program closes at 40/40 #4530's comment binds its deletion to this ruling) and prove tsc -p tsconfig.test.json still exits 0 with the imports resolving through the published surface.

Sequencing: gate worktree creation on PR #4530 (armed, green) being visible in origin/main — it owns the same two test files and the tsconfig this card edits. Disjoint from in-flight #4302/#4306 (app-shell), #4490 (plugin-grid), #4520 (plugin-timeline).

---

Generated by Claude Code

---

Generated by Claude Code