Out-of-scope finding from the #3883 / #3884 docs sweep (PR pending). Not fixed there — that PR's file surface is content/docs/guide/*.md only.
What was checked, on origin/main @ 11c1e71
packages/fields/package.json declares the subpath:
"exports": {
".": { "types": "./dist/index.d.ts", "import": "./dist/index.js", "require": "./dist/index.cjs" },
"./style.css": "./dist/index.css"
}
but nothing in that package appears to produce dist/index.css:
packages/fields/package.json scripts.build is tsc && vite build — no CSS step. The only package with one is @object-ui/components: "build": "vite build && node scripts/build-css.mjs", and scripts/build-css.mjs exists only there (grep -rln build-css --include=package.json packages/ returns one file).
packages/fields/src contains no .css file at all, and no module under it imports one (grep -rn 'import.*\.css' packages/fields/src is empty). Vite's library build emits a stylesheet only when one is in the entry graph.
packages/fields/vite.config.ts has no CSS entry or cssCodeSplit handling.
- Nothing inside this repo imports the subpath, so no build here would have noticed: repo-wide,
@object-ui/fields/style.css occurs only in content/docs/guide/quick-start.md. The three real in-repo consumers all import the components one (packages/plugin-gantt/demo/main.tsx, packages/plugin-grid/demo/main.tsx, packages/plugin-grid/demo/bulk-actions.tsx).
Why it matters
content/docs/guide/quick-start.md:57 teaches consumers to write @import "@object-ui/fields/style.css"; as step 3 of the first-run setup. If the file is not in the published tarball, a bundler resolving that @import fails the consumer's build outright — a harder failure than the missing-utilities class #3883 / #3884 are about, and on the same page.
What I did NOT verify, and how to settle it
I did not run the build: this was a docs-only worktree with no install, and the #3883 dispatch's measurement basis explicitly scoped me to cheap spot-verification. So the evidence above is a source read, not a measurement. The deciding runs are:
pnpm --filter @object-ui/fields build && ls packages/fields/dist/index.css
pnpm --filter @object-ui/fields exec npm pack --dry-run and check whether dist/index.css is in the file list.
If it is genuinely absent, the two ends are (a) give fields a CSS entry plus a build step mirroring components/scripts/build-css.mjs, or (b) drop the ./style.css export and the quick-start.md:57 line that teaches it. Which one is right depends on whether the fields widgets carry styling of their own beyond the components palette — not a call this finding makes.
Dedup
Searched open issues for fields style.css, "@object-ui/fields" css, exports dist/index.css build, subpath export missing file. Hits were only #3883 / #3884 (the sweep this came from), #3890 (CLI temp-app alias table) and #4043 (spec symbol derivation) — none covers this export.
Generated by Claude Code
Out-of-scope finding from the #3883 / #3884 docs sweep (PR pending). Not fixed there — that PR's file surface is
content/docs/guide/*.mdonly.What was checked, on
origin/main@11c1e71packages/fields/package.jsondeclares the subpath:but nothing in that package appears to produce
dist/index.css:packages/fields/package.jsonscripts.buildistsc && vite build— no CSS step. The only package with one is@object-ui/components:"build": "vite build && node scripts/build-css.mjs", andscripts/build-css.mjsexists only there (grep -rln build-css --include=package.json packages/returns one file).packages/fields/srccontains no.cssfile at all, and no module under it imports one (grep -rn 'import.*\.css' packages/fields/srcis empty). Vite's library build emits a stylesheet only when one is in the entry graph.packages/fields/vite.config.tshas no CSS entry orcssCodeSplithandling.@object-ui/fields/style.cssoccurs only incontent/docs/guide/quick-start.md. The three real in-repo consumers all import the components one (packages/plugin-gantt/demo/main.tsx,packages/plugin-grid/demo/main.tsx,packages/plugin-grid/demo/bulk-actions.tsx).Why it matters
content/docs/guide/quick-start.md:57teaches consumers to write@import "@object-ui/fields/style.css";as step 3 of the first-run setup. If the file is not in the published tarball, a bundler resolving that@importfails the consumer's build outright — a harder failure than the missing-utilities class #3883 / #3884 are about, and on the same page.What I did NOT verify, and how to settle it
I did not run the build: this was a docs-only worktree with no install, and the #3883 dispatch's measurement basis explicitly scoped me to cheap spot-verification. So the evidence above is a source read, not a measurement. The deciding runs are:
pnpm --filter @object-ui/fields build && ls packages/fields/dist/index.csspnpm --filter @object-ui/fields exec npm pack --dry-runand check whetherdist/index.cssis in the file list.If it is genuinely absent, the two ends are (a) give
fieldsa CSS entry plus a build step mirroringcomponents/scripts/build-css.mjs, or (b) drop the./style.cssexport and thequick-start.md:57line that teaches it. Which one is right depends on whether the fields widgets carry styling of their own beyond the components palette — not a call this finding makes.Dedup
Searched open issues for
fields style.css,"@object-ui/fields" css,exports dist/index.css build,subpath export missing file. Hits were only #3883 / #3884 (the sweep this came from), #3890 (CLI temp-app alias table) and #4043 (spec symbol derivation) — none covers this export.Generated by Claude Code