+ proj: derive the zui keyword from lib type and guard it - #246
Merged
Conversation
52 of 65 lib manifests disagreed with their own `zui.type`, in three ways: - 29 carried a `zui:` entry naming a different type (`panel` said `zui:control` while its type is `component`; `progress` and `progress-circle` said `zui:css-progress` and `zui:js-progress-circle`, which are not types at all). - 8 had `keywords` but no `zui:` entry. - 15 had no `keywords` field. Every manifest now carries exactly one `zui:<type>` entry matching `zui.type`. This is the mechanical half, generated by `scripts/libs/check-keywords.ts --fix`, which lands with its guard in the next commit. It comes first so that every commit in the series passes `pnpm check`. ## Scope Only the `zui:` entry. Free-form keywords (`css`, `js`, `components`) are left exactly as they are, in their existing order, and an existing `zui:` entry keeps its position in the array. Where the field was absent it is inserted after `browserslist`, `browser` or `version`, which is where the 50 manifests that already had it put it. Verified that no line outside a `keywords` array moved: comparing each manifest against its parent shows 0 changes to any other key, and 0 changes to key order. `lib/table` declares `keywords: ["css", "js", "components"]` while shipping no JS. Free-form keyword accuracy is outside this rule's scope, so it is left alone rather than quietly corrected here. ## No behaviour change `keywords` is read by nothing in this repo — `scripts/libs/query.ts:106-137` groups and orders libs from `zui.type` alone, and the field appears nowhere in `scripts/`, `vite.config.ts` or `tailwind.config.cjs`. This changes published metadata only.
`keywords` is read by nothing in this repo, so nothing kept it in step with `zui.type` and 52 of 65 manifests had drifted apart. Fixing them once only resets the clock; this makes the drift fail the build instead. ## Design `scripts/libs/check-keywords.ts` is one rule with writes optionally enabled, so the generator and the guard cannot disagree: - `checkLibKeywords(manifests)` is pure and returns a list of violations. - `--fix` is the same check applied, then re-run to confirm it converged. - `pnpm lib:keywords` runs it; `pnpm lib:keywords --fix` rewrites. `tests/unit/lib-keywords.test.ts` asserts zero violations across every manifest under `lib/`, and compares the violation *messages* rather than a count so a failure names the libs that drifted. It sits in the existing `unit` project, so `pnpm check` already runs it with no script changes. Exts are deliberately excluded from the scan: they are gitignored and absent on CI, so including them would make the guard's result depend on the machine. ## Writes stay surgical `--fix` edits the `keywords` array as text rather than re-serializing the manifest — a JSON round-trip expands the inline arrays this repo uses and turns a one-line diff into a whole-file rewrite. It preserves inline vs. multi-line arrays, indentation and CRLF endings, all covered by tests. ## Verified in both directions Corrupting `lib/panel`'s entry to `zui:control` fails the test with a message naming `panel`, and `--fix` restores the file byte-identically. `--fix` is idempotent: a second run reports all 65 clean and produces no further diff. An unusable `zui.type` is reported as `invalid-type` and marked unfixable rather than guessed at — `query.ts:106` already rejects those at build time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
52 of 65 lib manifests disagreed with their own
zui.type. This fixes them and adds aguard so they cannot drift again.
The state before
zui:entry naming a different typekeywordspresent, nozui:entrykeywordsfield at allTwo of the 29 were not drift but one-off strings matching no type at all:
progresssaidzui:css-progressandprogress-circlesaidzui:js-progress-circle.Why guard rather than just fix
keywordsis read by nothing in this repo.scripts/libs/query.ts:106-137groups andorders libs from
zui.typealone, and the field appears nowhere inscripts/,vite.config.tsortailwind.config.cjs. That is precisely why it drifted — nothing washolding it in step, so fixing it once only resets the clock.
Deleting the field would have been equally defensible. Keeping it and deriving it means
the metadata stays true without anyone having to remember it.
Design
scripts/libs/check-keywords.tsis one rule with writes optionally enabled, so thegenerator and the guard cannot disagree:
checkLibKeywords(manifests)is pure and returns violations.--fixis that same check applied, then re-run to confirm it converged.pnpm lib:keywordschecks;pnpm lib:keywords --fixrewrites.tests/unit/lib-keywords.test.tsasserts zero violations across every manifest underlib/, comparing violation messages rather than a count so a failure names the libsthat drifted. It sits in the existing
unitproject, sopnpm checkalready runs it withno script changes. Exts are excluded from the scan — they are gitignored and absent on CI,
so including them would make the result depend on the machine.
Scope of the rule
The
zui:entry only. Free-form keywords (css,js,components) are left exactly asthey are, in order, and an existing
zui:entry keeps its position.lib/tableclaimsjswhile shipping none — out of scope here, and left alone rather than quietly changed.Commit order
The manifest churn comes first, the tooling second, so every commit in the series
passes
pnpm check. Rule-first would leave one commit red forgit bisect.Verification
lib/panel's entry tozui:controlfails the test witha message naming
panel;--fixrestores the file byte-identically.--fixreports all 65 clean and produces no further diff.keywordsmoved. Comparing each manifest against its parent shows 0changes to any other key and 0 changes to key order — checked programmatically.
pnpm buildoutput is identicalacross all 22 artifacts. The 20 CSS files are byte-identical;
zui.jsandzui.esm.jsdiffer only in the embedded git hash and a wall-clock build stamp, which every build
embeds regardless of this change.
pnpm checkgreen: 10 test files / 76 tests, up from 9 / 60.Rebased onto
origin/dev_optimize@68d7e165d7. No file overlap with the six upstreamcommits, and none with #243.