Fact (measured on origin/main, unrelated to any in-flight PR)
packages/types/package.json's exports map:
"." : {
"types": "./dist/index.d.ts",
"import": "./dist/index.js",
"require": "./dist/index.cjs"
}packages/types's "build" script is bare "tsc" — no bundler, no dual-format step.
A clean rebuild (rm -rf dist tsconfig.tsbuildinfo && tsc) produces .js + .d.ts
(+ previously .d.ts.map, see #4851) and never an index.cjs. The require
condition of the root . export therefore resolves to a file the tarball never
contains — measured directly:
node-e"console.log(require.resolve('/path/to/packages/types/dist/index.cjs'))"// MODULE_NOT_FOUNDHow it was found
While implementing #4851 (the declarationMap / files trim for @object-ui/types),
the pre-existing-vs-introduced check for that PR walked every exports condition
against the freshly rebuilt dist and found this one missing. Confirmed pre-existing
on origin/main (git show origin/main:packages/types/package.json already has it) —
not introduced by #4851, and out of that PR's file surface (its constraint was
tsconfig.json + files array only).
Scope note — possibly wider, not fully measured
A quick grep found 23 packages across the repo declaring a "require": ".../index.cjs"
export condition. A few were spot-checked:
@object-ui/data-objectstack (tsup) — tsup emits .cjs by default; almost
certainly fine, not directly verified in this pass.@object-ui/fields (tsc && vite build && build-css, vite.config.ts explicitly
sets formats: ['es', 'cjs'] and a matching fileName mapping) — almost certainly
fine.@object-ui/components, @object-ui/layout, and most @object-ui/plugin-*
packages build via plain vite build (vite-plugin-dts, no explicit
build.lib.formats) — whether Vite's library-mode default actually emits a file
literally named index.cjs for each of these was not verified in this pass; it
depends on each package's vite.config.tslib.fileName/name settings, which
differ from file to file (e.g. layout's fileName: 'index' static string vs. a
format-aware function).
@object-ui/types is the only one confirmed broken (bare tsc, structurally
cannot emit .cjs). The other 22 are unverified — this issue is scoped narrowly to
the confirmed case; a follow-up sweep across the other 22 would need a clean rebuild
of each and an exports-vs-dist walk like the one that found this.
Why it matters, and why it's observation-class today
No consumer changes in this repo import @object-ui/types via require() — the repo
is ESM ("type": "module" everywhere), so this dead require condition is invisible
to every workspace consumer and to check-phantom-dependencies.mjs (which asks "is it
declared", not "does the exports map resolve"). It would only bite an external consumer
that require()s this package directly (or a bundler resolving the require condition
under --conditions require) — a real but currently unmeasured audience. Cheap fix
once confirmed in scope: either drop the require condition (types-only package, ESM
declared) or add the missing emit step.
Observation-class, unassigned.
Fact (measured on
origin/main, unrelated to any in-flight PR)packages/types/package.json'sexportsmap:packages/types's"build"script is bare"tsc"— no bundler, no dual-format step.A clean rebuild (
rm -rf dist tsconfig.tsbuildinfo && tsc) produces.js+.d.ts(+ previously
.d.ts.map, see #4851) and never anindex.cjs. Therequirecondition of the root
.export therefore resolves to a file the tarball nevercontains — measured directly:
How it was found
While implementing #4851 (the
declarationMap/filestrim for@object-ui/types),the pre-existing-vs-introduced check for that PR walked every
exportsconditionagainst the freshly rebuilt
distand found this one missing. Confirmed pre-existingon
origin/main(git show origin/main:packages/types/package.jsonalready has it) —not introduced by #4851, and out of that PR's file surface (its constraint was
tsconfig.json+filesarray only).Scope note — possibly wider, not fully measured
A quick grep found 23 packages across the repo declaring a
"require": ".../index.cjs"export condition. A few were spot-checked:
@object-ui/data-objectstack(tsup) — tsup emits.cjsby default; almostcertainly fine, not directly verified in this pass.
@object-ui/fields(tsc && vite build && build-css,vite.config.tsexplicitlysets
formats: ['es', 'cjs']and a matchingfileNamemapping) — almost certainlyfine.
@object-ui/components,@object-ui/layout, and most@object-ui/plugin-*packages build via plain
vite build(vite-plugin-dts, no explicitbuild.lib.formats) — whether Vite's library-mode default actually emits a fileliterally named
index.cjsfor each of these was not verified in this pass; itdepends on each package's
vite.config.tslib.fileName/namesettings, whichdiffer from file to file (e.g.
layout'sfileName: 'index'static string vs. aformat-aware function).
@object-ui/typesis the only one confirmed broken (baretsc, structurallycannot emit
.cjs). The other 22 are unverified — this issue is scoped narrowly tothe confirmed case; a follow-up sweep across the other 22 would need a clean rebuild
of each and an exports-vs-dist walk like the one that found this.
Why it matters, and why it's observation-class today
No consumer changes in this repo import
@object-ui/typesviarequire()— the repois ESM (
"type": "module"everywhere), so this deadrequirecondition is invisibleto every workspace consumer and to
check-phantom-dependencies.mjs(which asks "is itdeclared", not "does the exports map resolve"). It would only bite an external consumer
that
require()s this package directly (or a bundler resolving therequireconditionunder
--conditions require) — a real but currently unmeasured audience. Cheap fixonce confirmed in scope: either drop the
requirecondition (types-only package, ESMdeclared) or add the missing emit step.
Observation-class, unassigned.