chore: pin oxlint and oxlint-tsgolint to exact versions - #340
Open
sroussey wants to merge 1 commit into
Open
Conversation
`lint` runs oxlint with `--deny-warnings` and CI runs `lint`, so a floating caret range picks up a rule added to oxlint's `correctness` set on a minor release and turns CI red on a day nobody touched the code. This is the hazard oxfmt is already pinned exactly against, and that `typescript` is held to `~7.0.2` for. Pinned to the versions the lockfile already resolved — oxlint 1.81.0 and oxlint-tsgolint 7.0.2001 — so nothing upgrades here; the lockfile diff is the two range strings and no resolution change. tsgolint is pinned too because it supplies the type-aware rules and is oxlint's peer, so the pair moves together. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DdZebeeuQjgQTUszAjJDLb
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.
Why
lintruns oxlint with--deny-warnings, and CI runslint(.github/workflows/test.yml). Withoxlintdeclared as^1.81.0, a minor oxlint release that adds a rule to itscorrectnessset turns CI red on a day nobody touched the code.This is exactly the hazard the repo already pins against elsewhere:
oxfmtis0.66.0(the Formatting section of.claude/CLAUDE.mdspells out the reasoning), andtypescriptis held to~7.0.2. oxlint was the one tool in the trio still floating.What changed
oxlint:^1.81.0→1.81.0oxlint-tsgolint:^7.0.2001→7.0.2001.claude/CLAUDE.md, Linting section: two sentences recording the pin and why, matching the wording style already used for oxfmt.oxlint-tsgolintis pinned for the same reason — it supplies the type-aware rules, so a minor release of it can also add findings — and because oxlint declares it as a peer (oxlint-tsgolint: ">=7.0.2001"), the two are bumped together as one deliberate change.Deliberately left alone:
oxfmt(already exact),typescript(~7.0.2is patch-only and an existing deliberate constraint), and the non-lint devDependencies (vitest,concurrently,better-sqlite3,@types/*) — none of them gate CI on a rule set.No lint rule was changed, no staged-off rule flipped on, and
.oxlintrc.jsonis untouched.Freezing today's state, not upgrading
Both versions were read from
bun.lock, which already resolvedoxlint@1.81.0andoxlint-tsgolint@7.0.2001. Afterbun installthe lockfile diff is only the two range strings in the workspace devDependencies block — no resolution moved:Installed binaries confirm the same versions (
oxlint --version→1.81.0;node_modules/oxlint-tsgolint/package.json→7.0.2001).Verification
bun install, then the first three CI steps:bun run format-check— "All matched files use the correct format." (1143 files)bun run lint— exit 0, no findingsbun run build— bundle, both bin transpiles, andtscall clean, exit 0🤖 Generated with Claude Code
https://claude.ai/code/session_01DdZebeeuQjgQTUszAjJDLb
Generated by Claude Code