Repository navigation
fix(lint): compare the prose skip against a posix path - #5982
Conversation
`lint:ui-tokens` fails on a Windows checkout with 15 violations, every one of
them English out of a translation catalogue:
src\lib\i18n\en.ts:237: text-to-speech (to-speech is not a token this theme defines)
src\lib\i18n\en.ts:690: to-dos (dos is not a token this theme defines)
src\lib\i18n\it.ts:818: to-do (do is not a token this theme defines)
`holdsProseNotClasses` exists precisely to prevent this, and its own doc
comment names these exact strings. It never fires on Windows: `path.relative`
returns the platform separator, so the value it tests is `src\lib\i18n\en.ts`,
and `startsWith('src/lib/i18n/')` and `includes('/__tests__/')` both miss.
The catalogues are then read as class lists, where "text-to-speech" parses as
`text-` plus an undefined token.
The gate is in `.husky/pre-push`, so on Windows it blocks every push with a
failure the author cannot have caused and cannot silence — the suggested
remedy ("choose a defined semantic token") does not apply to prose.
Normalising to `/` before the comparisons is the whole change; the same walk
already yields platform paths to every other check, which are separator-blind.
Verified on this host: `node scripts/lint-undefined-scales.mjs` goes from
15 violations to `no undefined colour scales or tokens (30 shade-bearing
scales, 68 shadeless colours, 18 shadows)`, and reverting the two-line change
brings all 15 back.
How this change flows0 changed behaviours across 4 relationships. 5 surrounding behaviours are shown (60 graph nodes walked). 52 further behaviours left out to keep the diagram readable. flowchart LR
n0["join"]:::impacted
n1["relative"]:::impacted
n2["shadeResolver"]:::impacted
n3["absorbThemeCss"]:::impacted
n4["appRoot"]:::impacted
n1 -->|uses| n4
n2 -->|calls| n0
n2 -->|calls| n3
n2 -->|uses| n4
classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff
Green: changed behaviour. Grey: surrounding behaviour. Arrows name the call, use, implementation, or test relationship. Orange: has findings. Red: has a finding that blocks the merge. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe lint helper now normalizes relative paths to POSIX-style separators before applying prose and test-file checks. This makes the skip logic work correctly on Windows. ChangesCross-platform lint path handling
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This localized lint fix normalizes Windows paths so prose translation files are skipped correctly; no actionable merge-blocking risk remains beyond normal checks and review. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Warning Your free Security trial is over. An organization admin can upgrade to Advanced for continuous pull request security review or dismiss this notice. Comment |
…indows-sep\n\nfix(lint): compare the prose skip against a posix path\n
The defect
On a Windows checkout
pnpm lint:ui-tokensfails with 15 violations, and every one of them is English prose out of a translation catalogue:scripts/lint-undefined-scales.mjsalready has a guard for exactly this, and its doc comment names these exact strings:The guard never fires on Windows:
relativecomes frompath.relative, which yields the platform separator. Both/-spelled comparisons miss, the catalogues are scanned as class lists, andtext-to-speechparses as thetext-utility plus an undefined tokento-speech. Only the extension regex, which has no separator in it, still works.Why it matters beyond a noisy lint
The gate runs from
.husky/pre-push, so on Windows it blocks every push, on a failure the author cannot have caused and cannot act on — the remedy the script prints ("choose a defined semantic token — do NOT add a scale only to silence this lint") does not apply to ato-doin a sentence. The only ways past are--no-verifyor editing someone else's translations.It also hides real findings: the 15 false positives are the entire output, so a genuine undefined scale introduced on a Windows machine is indistinguishable from the noise.
The fix
Normalise to
/once, then compare. Nothing else in the script is separator-sensitive — the samewalk()hands platform paths to every other check, and those are separator-blind.Verification
On this host (Windows 11, Git Bash), against
main:node scripts/lint-undefined-scales.mjssrc\lib\i18n\no undefined colour scales or tokens (30 shade-bearing scales, 68 shadeless colours, 18 shadows)relativeThe reverted-comparison run is the part worth stating: it pins the cause on the separator rather than on anything else that moved.
I did not add a unit test —
lint-undefined-scales.mjsexecutes its scan at import time against a hard-codedappRoot/src, so testingholdsProseNotClasseswould mean extracting it, which is a larger change than the bug warrants. Happy to do that separately if you would rather have the seam.Summary by CodeRabbit