feat(lint): add the stx conformance checks to buddy lint - #2208
Merged
Conversation
Redo of the closed #2206, in the shape Chris asked for: a flag on the existing command rather than a command of its own, since more lint modes than stx are likely. ./buddy lint --stx Chapter 12 of the stx standards, plus three that read the build output. Those three exist because a real bug shipped past every source-level check: a mis-resolved component put an error string where the sidebar should have been on every built page, so the app shipped with no navigation and the developer's home directory in the HTML, and the build still exited 0. A ratchet, not a cliff. Counts are compared against baselines and the check fails BOTH above one and below one, because clearing a violation has to be recorded rather than quietly banked. A check with no entry is held at zero, so one added by a framework upgrade starts strict. What #2206 got wrong, and what changed: - Baselines were a `.stx-gate.json` dotfile in the repo root, against the convention `config/ui.ts` documents in its own comment. They now live in `config/lint.ts`, typed as `LintConfig`, alongside the other 45 configs. - There was a separate `stx-gate-types.ts` that nothing imported. The types are declared where they are used. - `--update` rewrote the baseline file. The linter no longer writes to source; a stale baseline prints the current counts ready to paste, which is the ergonomics the app-local original already had. Stacks' own baselines ship with it, each non-zero entry naming what clears it. Not wired into CI: the framework does not pass its own checks yet, and turning a red gate on is a separate decision from making the tool exist. Verified the ratchet both directions (regression fails, stale baseline fails), plain `buddy lint` unaffected, 241 buddy tests pass, pickier and both typechecks clean, command reference regenerated.
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
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.
Redo of the closed #2206, in the shape you asked for:
What #2206 got wrong
.stx-gate.jsondotfile in the repo rootconfig/lint.ts, typedLintConfig, alongside the other 45 configsstx-gate-types.tsnothing imported--updaterewrote the baseline fileThe dotfile was the worst of it —
config/ui.tsdocuments the convention in its own comment ("Stacks keeps every runtime-owned directory under storage/ rather than a.stxin the project root") and I put a JSON dotfile in the root anyway.What it checks
Chapter 12 of the stx standards, plus three that read the build output. Those three exist because a real bug shipped past every source-level check: a mis-resolved component put an error string where the sidebar should have been on every built page, so the app shipped with no navigation and the developer's home directory in the HTML — and the build still exited 0.
A ratchet, not a cliff
Counts are compared against
config/lint.tsbaselines, and the check fails both above a baseline and below one. Clearing a violation has to be recorded rather than quietly banked. A check with no entry is held at zero, so one added by a framework upgrade starts strict rather than inheriting whatever the project happens to have.Stacks' own baselines
Shipped with it, each non-zero entry naming what clears it:
stx-config-keysconfig/ui.tssetsstrict/root/pagesDirdoctype-no-nolayoutgenerateDocumentShellhtmlAttrsstyle-block<style>blocks move to crosswind preflightsdom-guardcoming-soon.stx/index.stxmove to signalsinline-style-attrdisplay:noneplain-internal-anchorindex.stx's brand link becomesStxLinkstx-config-keysis recorded as debt rather than fixed in passing: pinningroot+pagesDirchanges how stx resolves topology and wants its own dev+build pass, which is not a change a linter should make on a project's behalf.Not wired into CI. The framework does not pass its own checks yet, and turning a red gate on is a separate decision from making the tool exist.
Verification
Ratchet exercised both directions (regression → exit 1, stale baseline → exit 1 with the paste block), plain
buddy lintunaffected, 241 buddy tests pass, pickier clean, framework + app typechecks clean, command reference regenerated and passing.Once this lands, postline's
scripts/stx-gate.tsgets deleted rather than annotated — my note-adding commit there was the wrong call.🤖 Generated with Claude Code