What was observed
Noticed while adding @object-ui/fields as a third subject to
scripts/__tests__/plugin-published-stylesheet.test.ts (#6438). Filed rather
than ridden along: the fix is a producer-side change with its own review.
Three packages now ship a supplement stylesheet, and every one of them opens
with a banner that is part of the published artifact:
The emitted sheet is the header, then a newline, then the sheet body — see the
final assignment to css near the end of build() in
scripts/build-plugin-stylesheet.mjs. Nothing in the suite reads it. Surveyed
while working #6438: no assertion anywhere in scripts/__tests__/ inspects the
emitted stylesheet banner, so the banner bytes of all three published sheets are
unpinned. A change to defaultHeader, or an accidental drop of fields'
per-package header, would ship silently — the second case being a diff in a
published file that #6405 was explicitly gated against.
Why it was not fixed in #6438
The obvious assertion is "the emitted sheet opens with the banner this package
declares". It cannot be written cleanly today, because defaultHeader is a
module-private function in scripts/build-plugin-stylesheet.mjs — it is not
exported. A test covering all three subjects would therefore need a tolerant
fallback on the consumer side: read the package's own declared header, and fall
back to a locally re-spelled copy of the default for the two packages that
declare none.
That is exactly the consumer-side leniency this repo's contract-first rule says
to fix at the producer instead, and a second hand-maintained copy of the default
banner in the test would be free to drift from the real one while staying green
— the same "assertion that inspects nothing" shape #6438 records.
Suggested shape
Export defaultHeader from scripts/build-plugin-stylesheet.mjs (it is already
documented there as the per-package hook's counterpart), then add one
per-package assertion that the emitted sheet starts with the package's own
declared header when it has one, and with defaultHeader(PACKAGE_NAME) when it
does not — no second copy of the wording, and fields' published bytes pinned
where #6405 assumed they were.
Worth confirming rather than assuming: whether the maintainer wants the banner
pinned at all, or considers it presentation-only and deliberately unpinned.
Filed unassigned, as an observation from the #6438 implementation. Generated by
Claude Code, session 01GgDDqh6YnkXqsnVTCa7wHk — the standard attribution
footer is stripped from issue bodies written through this path, so it is stated
here as prose instead.
What was observed
Noticed while adding
@object-ui/fieldsas a third subject toscripts/__tests__/plugin-published-stylesheet.test.ts(#6438). Filed ratherthan ridden along: the fix is a producer-side change with its own review.
Three packages now ship a supplement stylesheet, and every one of them opens
with a banner that is part of the published artifact:
@object-ui/fieldspasses its ownheaderthroughbuildOptions(
packages/fields/scripts/build-css.mjs,HEADERat line 147, intobuildOptionsat line 168). Those exact bytes have been at the top of itspublished
dist/index.csssince @object-ui/fields declares a./style.cssexport but nothing buildsdist/index.cssfor it — the subpath quick-start teaches looks unresolvable #4059, and packages/fields/scripts/build-css.mjs duplicates the shared plugin stylesheet builder added for #4929 #6405's acceptance gate was thatre-pointing the build changed that file by not one byte.
@object-ui/plugin-gridand@object-ui/plugin-kanbanpass noheaderandinherit
defaultHeader(packageName)fromscripts/build-plugin-stylesheet.mjs.The emitted sheet is the header, then a newline, then the sheet body — see the
final assignment to
cssnear the end ofbuild()inscripts/build-plugin-stylesheet.mjs. Nothing in the suite reads it. Surveyedwhile working #6438: no assertion anywhere in
scripts/__tests__/inspects theemitted stylesheet banner, so the banner bytes of all three published sheets are
unpinned. A change to
defaultHeader, or an accidental drop of fields'per-package
header, would ship silently — the second case being a diff in apublished file that #6405 was explicitly gated against.
Why it was not fixed in #6438
The obvious assertion is "the emitted sheet opens with the banner this package
declares". It cannot be written cleanly today, because
defaultHeaderis amodule-private function in
scripts/build-plugin-stylesheet.mjs— it is notexported. A test covering all three subjects would therefore need a tolerant
fallback on the consumer side: read the package's own declared header, and fall
back to a locally re-spelled copy of the default for the two packages that
declare none.
That is exactly the consumer-side leniency this repo's contract-first rule says
to fix at the producer instead, and a second hand-maintained copy of the default
banner in the test would be free to drift from the real one while staying green
— the same "assertion that inspects nothing" shape #6438 records.
Suggested shape
Export
defaultHeaderfromscripts/build-plugin-stylesheet.mjs(it is alreadydocumented there as the per-package hook's counterpart), then add one
per-package assertion that the emitted sheet starts with the package's own
declared header when it has one, and with
defaultHeader(PACKAGE_NAME)when itdoes not — no second copy of the wording, and fields' published bytes pinned
where #6405 assumed they were.
Worth confirming rather than assuming: whether the maintainer wants the banner
pinned at all, or considers it presentation-only and deliberately unpinned.
Filed unassigned, as an observation from the #6438 implementation. Generated by
Claude Code, session
01GgDDqh6YnkXqsnVTCa7wHk— the standard attributionfooter is stripped from issue bodies written through this path, so it is stated
here as prose instead.