feat(linter/release): automate oxlint rule version updates#21392
feat(linter/release): automate oxlint rule version updates#21392camc314 merged 49 commits intooxc-project:mainfrom
Conversation
|
I put the release-version logic in a small |
There was a problem hiding this comment.
Pull request overview
This PR adds a small release-prep utility crate (oxc_release_rule_versions) and wires it into the release workflows to keep declare_oxc_lint! rule version = "next" metadata consistent and release-ready.
Changes:
- Added
tasks/release_rule_versionscrate withrewriteandchecksubcommands to rewrite/validate rule version metadata. - Updated release workflows to (a) rewrite rule versions during prepare-release and validate immediately afterward, and (b) validate rule versions as part of the release flow.
- Updated
Cargo.lockto include the new task crate.
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| tasks/release_rule_versions/src/main.rs | CLI entrypoint for rewrite / check commands with --root and --release-version. |
| tasks/release_rule_versions/src/lib.rs | Core implementation: rule-file discovery, macro parsing via syn, rewrite logic, validation logic, and regression tests. |
| tasks/release_rule_versions/Cargo.toml | New internal task crate manifest and dependencies. |
| Cargo.lock | Adds oxc_release_rule_versions to the lockfile. |
| .github/workflows/release_apps.yml | Adds Rust setup and rule-version validation in the release pipeline as defense in depth. |
| .github/workflows/prepare_release_apps.yml | Adds rewrite + immediate validation steps during release preparation. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e17d7f7198
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
camchenry
left a comment
There was a problem hiding this comment.
Thanks for working on this! This looks in the right direction, but I think this is a bit overcomplicated for what we need. At its core, this is a simple string replacement. We turn version = "next" into version = "1.2.3", with some caveats (like handling nursery rules). Some general thoughts on how to make this simpler:
- Let's make this a JavaScript script that we run with node. No Rust source code parsing, so it will be simpler and faster. General workflow:
- Find .rs files that contain the text
version = "next". Maybe do a check it's in thedeclare_oxc_lint!block too. - For those files, check if the category is set to nursery.
- If we should update, replace the version text range with the new version text.
- Find .rs files that contain the text
- We don't need a separate
checktool - we only ever call this after we just rewrote the version, so this is redundant. I don't think we need the check in release_apps.yml either - we only need to update it when a release is performed, that should be good enough I think - Output a simple report of what was changed (list of files modified and what was replaced?)
- Maybe add a
--dry-runoption too or something just in case
|
I'd recommend taking a look at this equivalent from Biome: https://github.com/biomejs/biome/blob/eaa7d3a7d57f1e08098c94a36aff374e5565d2e4/scripts/update-next-version.sh#L31, but implementing it as a node script instead of shell. |
|
Alright, I'll take a look. Thank you for your guidance. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eddc109285
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: af2b4a8591
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Thanks again for the simplification suggestion. I updated the PR to follow that direction more closely. The release-version update is now handled by a small Node script instead of the earlier Rust-based approach. It keeps the flow focused on the actual need here: rewriting stable I also hardened a couple of edge cases that came up in review:
Both of those now have regression tests as well. When you have time, could you please take another look? cc @camchenry |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c5366b32d8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7ba0b354ae
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c2e9888b58
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 54063d5ad2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 367837771c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 72776c512a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
camchenry
left a comment
There was a problem hiding this comment.
ok @camc314 I think this is good to go, if you want to take another look too since it's release related. I've tried to really simplify this down to only the things we actually need since we probably don't want any complex workflows in our release pipeline.
to that end, the tests were helpful while developing this, but I don't think we'll need them long-term, so I deleted them. at this point, I don't expect us to need to make lots of changes that justifies running the tests all the time. keeps things simpler too.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0ec0db253e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
camc314
left a comment
There was a problem hiding this comment.
Thanks - looks good to me!
## Summary This PR covers the Oxc-side export path for rule `version` metadata from #19890. It makes `version` available to non-`ruledocs` consumers, then threads that metadata through the existing export surfaces used by docs/tooling: - add `version` to `RuleTableRow` - include `version` in `oxlint` rules JSON output - include `version` in generated rule doc frontmatter for `website_linter` - add regression coverage for the JSON and doc-page export paths This replaces the earlier stacked fork PR now that its two prerequisites have already landed: - #21391: metadata backfill + guardrails - #21392: release automation ## Notes - This PR is intentionally scoped to the `oxc` repository only. - The website rendering change should remain a follow-up in `oxc-project/website`. - Compared with the earlier stacked branch, this version is rebased onto current `main` and aligns with the now-merged compile-time `version` invariant. ## Testing ```bash cargo fmt --all cargo lintgen cargo test -p oxlint output_formatter::json::test::all_rules_json_includes_version_metadata -- --nocapture cargo test -p oxlint lint::test::test_rules_json_output -- --nocapture cargo test -p website_linter cargo test -p oxc_linter --test rule_configuration_documentation_test --features ruledocs cargo test -p oxc_linter --features ruledocs ``` ## AI Usage Disclosure I used AI assistance to help inspect the prior stacked PR state, rebase the export slice onto the current `main`, and prepare the replacement PR text. I manually reviewed the resulting changes, ran the checks listed above, and remain responsible for the final code and submission.
Summary
This PR covers the release automation follow-up from #19890.
It replaces the earlier Rust-based prototype with a small Node script,
.github/scripts/update-rule-versions.js, that scansdeclare_oxc_lint!declarations undercrates/oxc_linter/src/rules/**and:version = "next"entries to the actual oxlint release version during release prepnurseryrules onversion = "next"version = "next"remains at release time--dry-runfor local verificationThe implementation also now hardens a few failure modes that came up during review:
declare_oxc_lint!blocks are ignored when parsing metadata// ...and single-line/* ... */comments on metadata lines are handled correctlyversion = "next"are not misclassified as invalid matchesversion = "next"is found outside adeclare_oxc_lint!blockWorkflow changes:
.github/workflows/prepare_release_apps.ymlsets up Node and runs the rewrite script aftercargo release-oxc update.github/workflows/release_apps.ymlsets up Node, reruns the script with the released oxlint version, and then checksgit diff --exit-code -- crates/oxc_linter/src/rulesTesting
node --test .github/scripts/update-rule-versions.test.js node .github/scripts/update-rule-versions.js --root . --release-version 1.61.0 --dry-run cargo check -p oxc_linter --lockedNotes
This PR intentionally does not include the docs/website wiring from #19890.
That should stay in a follow-up PR since it touches a different data flow and also involves
oxc-project/website#937.AI Usage Disclosure
I used AI assistance to help inspect the release workflows, compare the implementation direction against the maintainer feedback, and draft the initial automation changes. I manually reviewed the final implementation, added the regression tests for the workflow guard and parser edge cases above, ran the checks listed here, and remain responsible for the final code and submission.