finding(react): the built dist emits extensionless relative imports, so plain Node ESM cannot load the published entry

[yinlianghui]

Observation-class finding, tripped over while verifying #4529's published-surface claim under Node's own resolution (PR #4537). Not something a user meets today through the normal bundler path, and no test covers it — filed so it is recorded rather than rediscovered.

What

packages/react/dist/index.js re-exports through extensionless relative specifiers:

from './LazyPluginLoader'
from './SchemaRenderer'
from './context'
from './data-invalidation'
from './hooks'
from './spec-bridge'

Node's ESM resolver does not do extension search for relative specifiers, so loading the built entry under plain Node fails:

code: 'ERR_MODULE_NOT_FOUND',
url: 'file:///.../packages/react/dist/SchemaRenderer'

How it surfaced

#4529 was about whether two @object-ui/plugin-charts specifiers resolve through the published surface, so the check was run the way a real consumer would run it. Resolution itself is fine and the card's own claim held:

@object-ui/plugin-charts                        =>  packages/plugin-charts/dist/index.js
@object-ui/plugin-charts/normalizeChartSchema   =>  REFUSED ERR_PACKAGE_PATH_NOT_EXPORTED
@object-ui/plugin-charts/AdvancedChartImpl      =>  REFUSED ERR_PACKAGE_PATH_NOT_EXPORTED

But actually evaluating the resolved entry walks into @object-ui/react, and that is where it stops. So the failure is one package over from where it was found, and it is about loading, not about exports maps.

Why it is finding and not queued

Every consumer this repo actually exercises goes through a bundler — vite, and the app builds — and bundlers resolve extensionless relative imports happily. That is why the whole test suite, every example app and CI are green with this in place. The paths where it would bite are the unbundled ones: plain Node ESM, an SSR host importing the package directly, or a consumer running the published tarball under node --experimental-* without a build step.

So it is dormant rather than broken, and whether those paths are supported is a product call, not a code one:

• They are supported — then the emitted specifiers need extensions (a build/emit setting), and a smoke check that imports each published entry under plain Node would keep it that way.
• They are not — then the packaging is correct as-is for a bundler-only contract, and the thing worth adding is a line saying so, since the current state reads as an accident rather than a decision.

Worth noting the asymmetry: plugin-charts' own emitted entry is clean, and this only appears once evaluation crosses into @object-ui/react, so a per-package check that stops at resolution would not catch it. Whatever check is chosen has to actually load the entry, not just resolve it.

Unassigned, and no dependency on #4529 or #4537 either way — those landed on the resolution question, which is independent of this one.

---

Generated by Claude Code