published ESM contains directory imports, so no node-environment spec can render Dialog or CommandDialog

[woksin]

Describe the bug

This issue is filed from a production Cratis consumer. The complete measured, source-traced, cold-read report follows.

Status: OPEN — filed 2026-08-07. Kind: defect (packaging). Package: @cratis/components (/Dialogs, /CommandDialog).

The defect

Both barrels that reach Dialog import PrimeReact submodules as directory specifiers — primereact/progressspinner, primereact/stepper — rather than full file specifiers. Node's ESM resolver refuses a directory import, and vi.mock cannot intercept it because the package is externalized.

Consequence for any consumer whose test environment is node: Dialog and CommandDialog cannot be rendered in a spec at all.

Where Ada paid the cost

Source/Core/Compliance/Retention/Confirm/ConfirmDialog.tsx — the dialog that authorises irreversible deletion of a person's personal data, the only path by which that happens (D82).

A review found a one-keystroke destruction path there (autoFocus on the OK button plus a repeating Enter). Ada closed it with an acknowledgement gate, and specced its own half — the gate is shut at mount, the acknowledgement is present, gate and checkbox move as one state. ⚠️ The upstream half — that Cratis honours a shut gate (disabled: !isDialogValid || isBusy) — is verified by READING Dialog.js and is unspecifiable in Ada. So the safety property of the erasure screen rests on a source read that no gate re-checks, and a change to that expression would be invisible to Ada's entire suite.

The seam wanted

Emit full specifiers in the published ESM (primereact/progressspinner/progressspinner.esm.js, or whatever the correct entry is). Nothing about the components changes; the ask is packaging only.

⚠️ Not a request for a jsdom environment on Ada's side. Ada's environment choice is Ada's, and the same defect blocks every node-environment consumer; a consumer working around a packaging bug by changing its test runtime is not a fix.

[woksin]

Investigated and reproduced against the published tarball (npm pack @cratis/components@2.7.2), not just the local build. Three findings change what this issue should ask for.

1. The proposed fix does not work

The ask was to emit full specifiers — primereact/progressspinner/progressspinner.esm.js. Measured, that still fails:

FAIL primereact/progressspinner/progressspinner.esm.js  ERR_UNSUPPORTED_DIR_IMPORT
  Directory import '…/node_modules/primereact/api' is not supported resolving ES modules
  imported from …/node_modules/primereact/progressspinner/progressspinner.esm.js
FAIL primereact/api/api.esm.js  ERR_UNSUPPORTED_DIR_IMPORT :: … 'primereact/utils' …

PrimeReact's own ESM files use directory specifiers internally — 155 *.esm.js files import bare primereact/.... No rewrite inside @cratis/components can make the emit node-loadable while primereact stays external.

2. The root cause is upstream, and it is fixed in PrimeReact 11

primereact@10.9.8 ships no exports field — only main + module — so primereact/progressspinner resolves to a directory containing a legacy package.json, exactly the shape node's ESM resolver refuses. 10.9.8 is the terminal v10-stable release, so there is no patch-level escape inside v10.

primereact@11.1.0 ships:

{ "exports": { ".": {...}, "./*": { "types": "./*/index.d.ts", "import": "./*/index.mjs" } }, "type": "module" }

A wildcard map fixes our specifiers and PrimeReact's 155 internal ones at once, with no change to rollup.config.mjs or our exports map. That makes the real fix a major (v10→v11 API migration reaches all 26 emitted files, the re-exported .d.ts types, and every consumer importing primereact/* directly per components.md).

Two alternatives were measured and rejected: rewriting to *.cjs.js loads, but splits PrimeReact's React context (PrimeReactContext identical across cjs/esm entries? false) so theming/pt/locale silently stop working; bundling PrimeReact has the same hazard plus duplication.

3. The scope is wider than the title, and there is a second blocker

17 of 18 published exports subpaths are unloadable in node ESM — /types is the only survivor. 41 primereact imports across 26 emitted files, 22 distinct subpaths, all directory imports.

And a separate blocker the issue does not mention: 13 CSS side-effect imports in the shipping ESM.

FAIL ./dist/esm/CommandDialog/CommandStepper.js  ERR_UNKNOWN_FILE_EXTENSION :: Unknown file extension ".css"

With directory imports repaired, /Dialogs loads cleanly — but /CommandDialog still fails on CommandStepper.css. Fixing this issue as written would unblock Dialog but not CommandDialog, which is half the title. /Toolbar, /Filter and /PivotViewer are blocked the same way.

4. Why no spec caught it, and why no spec can

Three independent reasons, each sufficient:

• Every Dialog/CommandDialog spec imports source (from '../Dialog'), never the emit; vite.config.ts:62 excludes **/dist/** from the test glob.
• The specs vi.mock('primereact/dialog') — the module whose resolution is the defect is replaced by a factory, so its specifier is never resolved.
• The runner cannot host the failure. Loading the exact files node rejects, through Vite's own resolver: vite ssrLoadModule OK /dist/esm/Dialogs/index.js. Vite resolves directory imports and .css happily. Even a spec pointed at dist/ passes green.

And CI never builds the published shape at all. javascript-build.yml runs yarn ci → the workspace build is tsc -p tsconfig.json — tsc only, no rollup. Rollup runs exclusively in prepare, during npm publish. The artifact that ships is never built in CI and never tested anywhere. (The tsc-only emit is also node-illegal for a different reason: export * from './BusyIndicatorDialog' — extensionless — and no dist/esm/package.json marking it as ESM.)

The honest gate is therefore not a vitest spec but a check script that spawns a real child node process per published subpath and asserts exit 0 — wired into prepare so it gates the publish, plus a CI step that actually runs prepare. That gate is red on main today (17/18), which is what makes it worth having. I have not wired it in, because a red gate in prepare would block publishing until the v11 decision lands — that sequencing is the maintainer's call.

Interim, consumer side, no upstream change

test.server.deps.inline: ['@cratis/components'] in the consumer's vitest config puts the package in Vite's graph, so directory imports resolve and vi.mock('primereact/dialog') becomes interceptable again. This is not a jsdom switch, so it respects the original constraint.

One caveat worth recording: with the imports repaired, renderToStaticMarkup(<Dialog visible isValid={false}/>) returns empty output — PrimeReact's Dialog renders through a portal. So a packaging fix alone does not give a renderToStaticMarkup consumer an assertable render; it needs a mocked primereact/dialog or a DOM.

[woksin]

Correction to my previous comment: the fix already exists as an open PR — #107.

I concluded that the only real fix is upgrading PrimeReact v10 → v11, because v10.9.8 ships no exports field and v10.9.8 is the terminal v10-stable release. I should have checked open PRs before saying that was blocked on a decision. #107 "Migrate @cratis/components to PrimeReact 11" has been open since 2026-07-16, is already labelled major, and spans 149 files (+5133/−1981).

Its own summary says the breaking changes are "the unavoidable consequences of v11 being ESM-only" — which is precisely the property that closes this issue. So this is not a new piece of work to schedule; it is a reason to land #107.

Two things that follow:

#107 is currently CONFLICTING and was last updated 2026-07-16, so it needs a rebase before it can go anywhere.

It carries a licensing decision this issue does not. Per its description, PrimeReact 11 gates the styled @primeuix/themes presets behind a PrimeUI key, showing an "Invalid PrimeUI License" banner in dev and prod without one. #107 adds a license-free Cratis baseline theme as a third path. That is a product decision well beyond the scope of a packaging defect, and it should be weighed on #107, not here.

What this issue should still carry, because #107 does not appear to cover it:

1. The CSS side-effect blocker is independent of PrimeReact. 13 import './X.css' statements survive into the shipping ESM. Even with every directory import repaired, /CommandDialog still fails:

   FAIL ./dist/esm/CommandDialog/CommandStepper.js  ERR_UNKNOWN_FILE_EXTENSION :: Unknown file extension ".css"
   

   /Toolbar, /Filter and /PivotViewer are blocked the same way. A v11 migration does not fix this on its own.

2. CI never builds the published shape, so nothing would catch a regression either way. javascript-build.yml runs yarn ci, whose workspace build is tsc -p tsconfig.json — tsc only, no rollup. Rollup runs exclusively in prepare, during npm publish. The artifact that ships is never built in CI and never tested.

3. The honest gate is a script that spawns a real child node process per published exports subpath and asserts exit 0. It is red on main today (17 of 18 subpaths fail). I have not wired it in, because a red gate in prepare would block publishing until Migrate @cratis/components to PrimeReact 11 #107 lands — that sequencing is a maintainer call.

[woksin]

Confirmed blocked on #107 — with one correction to the description and one carve-out.

The proposed fix cannot work. Verified from the pinned dependency: primereact@10.9.8 ships no exports field, and primereact/dialog/dialog.esm.js itself imports bare primereact/api, primereact/utils, primereact/portal. So emitting full specifiers just relocates the failure one level in. npm dist-tags confirm v10-stable: 10.9.8 is terminal, while 11.1.0 ships "type": "module" plus a "./*" wildcard exports map that repairs our 50 import sites and PrimeReact's internal ones at once. Also worth correcting: the offending specifiers are bare primereact/*, externalized by rollup.config.mjs:92-105 with preserveModules: true — not relative extensionless folder imports. The 562 relative imports are illegal only in the tsc emit, which is never published.

But #107 does not close this issue. At feat/primereact-11-migration, rollup.config.mjs:102 still externalizes /\.css$/ and CommandDialog/CommandStepper.tsx:18 still has import './CommandStepper.css'. There are 12 CSS side-effect imports on main reaching 8 subpaths — CommandDialog, Common, DataPage, Filter, ObjectNavigationalBar, PivotViewer, TimeMachine, Toolbar. After #107, /Dialogs will load and /CommandDialog still will not — which is half the title of this issue.

Suggested split:

1. Keep published ESM contains directory imports, so no node-environment spec can render Dialog or CommandDialog #118 open past Migrate @cratis/components to PrimeReact 11 #107 for the CSS half (drop the JS-level CSS imports, fold component CSS into the already-published ./styles entry).
2. Land a publish gate separately and now — a verify-exports.mjs that spawns a child node per exports subpath and asserts exit 0. build is still tsc -p tsconfig.json, so CI never builds the published shape at all; that is why this went unnoticed. Tooling-only, patch, and it should start as a reporting job since it is red today.

PR #127 cross-references this but does not fix it — it touched only stepper counts and paginator framing.

[woksin]

Measured, not estimated. #131 adds a gate that spawns a child node per exports subpath and loads the real package specifier, so resolution goes through the exports map exactly as a consumer's does. Running it against a real prepare build of origin/main:

29 checks failed across 21 subpaths. Of the JS subpaths, only ./types loads under ESM. Every other one fails on either ERR_UNSUPPORTED_DIR_IMPORT (a bare primereact/* directory) or a CSS file.

This changes what we thought #107 would fix. The CJS column is a natural experiment for the post-PrimeReact-11 world: require resolves directories fine, so ERR_UNSUPPORTED_DIR_IMPORT never appears there — and 12 subpaths still fail, every single one on a .css file. ./Toolbar, ./Filter and ./PivotViewer fail on CSS even under import, before the loader ever reaches a primereact specifier.

Concretely, ./Toolbar [import] dies with ERR_UNKNOWN_FILE_EXTENSION: Unknown file extension ".css" for dist/esm/Toolbar/Toolbar.css. No PrimeReact version can fix that.

So my earlier note here understated it in two ways: the CSS reach is 12 subpaths, not 8 (add ., ./CommandStepper, ./ObjectContentEditor, ./SchemaEditor), and after #107 lands roughly two-thirds of the export surface would still be unloadable in Node. #118 should stay open past #107 for the CSS half — dropping the 13 CSS specifiers from the JS graph and folding component CSS into the already-published ./styles entry.

The gate is deliberately non-blocking, because it is red today by design — it reproduces this issue. It becomes blocking once both halves are fixed. The reason this reached a release at all is that build is tsc -p tsconfig.json while the real artifact comes from prepare (tsc -b && rollup -c), so CI has never once imported the published shape.