refactor(language_server): `provided_commands` and `provided_code_action_kinds` for `ToolBuilder` by Sysix · Pull Request #15608 · oxc-project/oxc

Sysix · 2025-11-11T18:05:56Z

This PR refactors the language server to make the system more extensible by introducing provided_commands and provided_code_action_kinds trait methods to ToolBuilder. This allows tools to declaratively specify their capabilities rather than hardcoding them in the capabilities module.

Just updated wrongly copied tests.

Also add an additional test from the upstream plugin.

…groups (#15578) Current implementation was performimg sort based on hard-coded `enum`. This PR changed it to use group definitions like this. ```js [ 'type-import', ['value-builtin', 'value-external'], 'type-internal', 'value-internal', ['type-parent', 'type-sibling', 'type-index'], ['value-parent', 'value-sibling', 'value-index'], 'ts-equals-import', 'unknown', ] ``` > https://perfectionist.dev/rules/sort-imports#groups And this will be refactored in the subsequent 2 PRs.

…ents` (#15579)

- Before: Compute metadata for sort inside of `sort_by()` - After: Collect these data before `sort_by()`

Fixes #15555

…15584) > I think we don't need to add another benchmark for the sort import feature; enabling it in > formatter.rs is enough. Any of the current benchmark files contains many import statements. It seems there was no need to create a separate file after all. My intention was to confirm that the benchmark for the formatter alone consistently produced better results than the benchmark with sorting enabled. To verify this, shouldn't the benchmarks be separated?

…ew JavaScript APIs (#15581) This will cause new violations for some users if they're using particularly new APIs, but that should be fine. For users migrating from the ESLint plugin, I wonder if we should consider calling out in the docs that this rule (and other rules of this nature) will potentially differ from the original Unicorn rule due to data updates over time? I ran into problems with the jsx-a11y rule in my work codebase due to this kind of improvement, so it may be worth calling out. This also renames `animationStart` and `animationEnd` to be lowercase, as I believe this discrepancy was a mistake in the porting process. The original rule undercases these when processing them with vendor prefixes: https://github.com/sindresorhus/eslint-plugin-unicorn/blob/609d4870f3731d39bd5b5f184628e2cf06578dba/rules/shared/dom-events.js Sources: - https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes#list_of_global_event_handler_attributes - https://github.com/mdn/browser-compat-data/blob/d5d5f2e21ef3f798784d1f5f75bde7c7f10f250e/api/Element.json - https://github.com/microsoft/TypeScript-DOM-lib-generator/blob/f915ac0c987300d75af41bfe4a34bb29a0fb941f/baselines/dom.generated.d.ts I used AI to compare the lists since they're in such different formats and then checked against MDN to ensure the additions were actually real. Prompt for future reference, since I think the pattern is useful: ``` Are there any onX methods defined here: \`\`\` declare var onabort: ((this: Window, ev: UIEvent) => any) | null; // and so on from here... \`\`\` That are not defined in this Rust array?: \`\`\` paste the DOM_EVENT_TYPE_NAMES array from the Rust file here \`\`\` Note that the list in rust strips out the `on` at the start. Capitalization differences matter. Link the MDN page for each function if it isn't found in the Rust list, please. ``` Will have to grab the first list from one of the sources above, I used the TS DOM lib generator because it tends to be quite up-to-date. Also remove the backslashes, obviously. I also added a comment about sourcing this data for future reference.

…c_release.toml` (#15585)

Updates submodule dependencies to their latest commits. ## Changes - test262: `d2940bd` → `fd594a0` - babel: `4cc3d88` → `777ded7` - TypeScript: `8ea03f8` → `48244d8` - prettier: `011791f` → `9e9f65e` - acorn-test262: `994d763` → `9cce4c9` - node-compat-table: `17ac85c` → `6822522` This PR is automatically generated by the [update_submodules workflow](https://github.com/oxc-project/oxc/blob/main/.github/workflows/update_submodules.yml). Co-authored-by: Boshen <1430279+Boshen@users.noreply.github.com>

#15591) Add path to CI workflow file to the watch list for "AST Changes" CI task, so the task runs if the workflow is altered.

We used to use `dprint` in `oxc_ast_tools`, but #15064 switched to `oxfmt`. Remove `dprint` tool from the "AST changes" CI task.

…fixtures (#15593) We don't use `dprint` any more to format JS/TS. So remove defunct `// dprint-ignore-file` comments from test fixtures.

…e-extension rule (#15574) Allow `tsx` to work fine for the rule config, previously it would be thrown out. Also update the help diagnostic to note which extensions are allowed by the current config, and add a few more tests. Fixes #15508 --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com> Co-authored-by: Cameron Clark <cameron.clark@hey.com>

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [napi](https://github.com/napi-rs/napi-rs) | dependencies | patch | `3.5.0` -> `3.5.2` | | [napi](https://github.com/napi-rs/napi-rs) | workspace.dependencies | patch | `3.5.0` -> `3.5.2` | | [napi-derive](https://github.com/napi-rs/napi-rs) | dependencies | patch | `3.3.0` -> `3.3.3` | | [napi-derive](https://github.com/napi-rs/napi-rs) | workspace.dependencies | patch | `3.3.0` -> `3.3.3` | --- ### Release Notes <details> <summary>napi-rs/napi-rs (napi)</summary> ### [`v3.5.2`](https://github.com/napi-rs/napi-rs/releases/tag/napi-v3.5.2) [Compare Source](https://github.com/napi-rs/napi-rs/compare/napi-v3.5.1...napi-v3.5.2) ##### Other - updated the following local packages: napi-build ### [`v3.5.1`](https://github.com/napi-rs/napi-rs/releases/tag/napi-v3.5.1) [Compare Source](https://github.com/napi-rs/napi-rs/compare/napi-v3.5.0...napi-v3.5.1) ##### Fixed - *(napi)* TypedArraySlice creation ([#3004](https://github.com/napi-rs/napi-rs/pull/3004)) ##### Other - *(napi)* Promise and ThreadsafeFunction::call\_async don't require tokio ([#2998](https://github.com/napi-rs/napi-rs/pull/2998)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/oxc-project/oxc).

Part of #11490 ### Motivation `AstKind::Argument` was an architectural inconsistency. The AstKind system is designed for struct types, but `Argument` is an enum (`SpreadElement | Expression`). This created unnecessary complexity in the AST traversal system. ### Solution Replace AST-based argument detection with span-based utilities. Instead of traversing the tree to find `AstKind::Argument` nodes, we now use direct span containment checks. ### New Utilities **Added to `oxc_linter/src/ast_util.rs`:** ```rust pub fn is_node_exact_call_argument<'a>( node: &AstNode<'a>, ctx: &LintContext<'a> ) -> bool ``` Checks if a node is exactly a direct argument to its parent call expression by checking if the parent is a call and the node's span matches one of the argument spans. ```rust pub fn is_node_within_call_argument<'a>( node: &AstNode<'a>, call: &CallExpression<'a>, target_arg_index: usize, ) -> bool ``` Checks if a node is nested within a specific argument at the given index of the provided call expression. **Added to `oxc_ast/src/ast_kind_impl.rs`:** ```rust pub fn has_argument_with_span(&self, span: Span) -> bool ``` Checks if this `AstKind` is a call expression with an argument matching the given span. ```rust pub fn is_callee_with_span(&self, span: Span) -> bool ``` Checks if this `AstKind` is a call expression whose callee matches the given span. ### Architecture Change **Before:** ```rust // Required parent traversal and state management match parent.kind() { AstKind::Argument { .. } => { // Check grandparent for call context } } ``` **After:** ```rust // Direct span-based detection if is_node_exact_call_argument(node, ctx) { // Node is a direct call argument } if is_node_within_call_argument(node, call, 0) { // Node is within first argument } ``` --------- Co-authored-by: Cameron Clark <cameron.clark@hey.com>

Format `oxlint` test fixtures. The directory `fixtures` contains not just the fixtures themselves, but also Oxlint plugins, which should be formatted. Skip 2 specific test fixture files which must not be formatted to maintain correctness of the tests.

…tion (#15507) Closed #15178

… configuration options (#15234) Fixes #15095. This was implemented with considerable help from GitHub Copilot using Claude Sonnet 4.5, and advice from camc in the discord. It should be noted that this technically also does not enforce that the config options be _documented_, it currently only checks that there are config options in the debug output for the Rule's emitted default value. We could potentially evaluate the emitted schema more deeply to ensure all options have documentation info as well, but that would require more work and should maybe be a separate test. This test enforces the config schema usage by taking the following steps: - Get all rules in the repo - Establish an 'exceptions' list for rules we have not converted yet - Go through each rule, for each: - If the rule is in the exceptions list, make sure it has no schema (if it does, fail) and then skip to the next rule. - Check if the rule has a schema, and skip to the next rule if it does. - Generate the debug output for the rule's default shape, and then check if it has characters which would suggest it has config options (any of `{}[]` or more than one layer of nested `()`). - Return failures at the end. It also ensures that all rules in the exceptions array are defined rules. ~~Note that `react/state-in-constructor` and `vue/define-emits-declaration` are missed by this, they should error if removed from `exceptions`, but do not get caught as rules that have configuration options. This is because they are using enum-only configs (e.g. `"plugin/rule": ["error", "never"]`), and so don't emit a debug string with `{}` or `[]` in them. Currently, if you remove the exceptions array entirely, this will find 27 of the 29 known violations in the codebase. So it's _probably_ sufficient for now.~~ I fixed this problem, so it now discovers 29/29 violations. The output for a failure looks like this: ``` running 1 test test test_rules_with_custom_configuration_have_schema ... FAILED failures: ---- test_rules_with_custom_configuration_have_schema stdout ---- thread 'test_rules_with_custom_configuration_have_schema' (44628423) panicked at crates/oxc_linter/tests/rule_configuration_documentation_test.rs:151:5: Found 3 configuration documentation issues: Rule 'react/forbid-elements' accepts configuration options but has no schema defined. Please see the oxc website for info on adding config option schemas and docs to this rule. https://oxc.rs/docs/contribute/linter/adding-rules.html Rule 'react/jsx-handler-names' accepts configuration options but has no schema defined. Please see the oxc website for info on adding config option schemas and docs to this rule. https://oxc.rs/docs/contribute/linter/adding-rules.html Rule 'react/prefer-es6-class' accepts configuration options but has no schema defined. Please see the oxc website for info on adding config option schemas and docs to this rule. https://oxc.rs/docs/contribute/linter/adding-rules.html note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` --------- Co-authored-by: Cameron <cameron.clark@hey.com>

Fix #15564. `oxc_ast_tools` depends on Oxc crates from crates.io, not the local workspace. When AST changes break local crates, the codegen can't compile either - a Catch-22 situation, since running codegen is the only way to fix compilation. This isn't ideal as it complicates dependency management. Alter `oxc_ast_tools` so it depends on crates from local workspace, and work around the Catch-22 problem by introducing a `generate-js` Cargo feature which disables these dependencies, so the codegen can still compile if they're broken. ## Changes - **Add `generate-js` Cargo feature** (enabled by default) - Makes all `oxc_*` dependencies optional, activated only when feature enabled. - Only JS generators (`RawTransferGenerator`, `TypescriptGenerator`, `ESTreeVisitGenerator`, `RawTransferLazyGenerator`) require these dependencies. - **Conditional compilation** - Gate JS generator modules and `Output::Javascript` variant behind `#[cfg(feature = "generate-js")]` - **Fallback in `just ast`** ```sh cargo run -p oxc_ast_tools || ( cargo run -p oxc_ast_tools --no-default-features && cargo run -p oxc_ast_tools ) ``` First attempts to run full codegen. On failure, regenerates Rust code only, without dependencies (so that `oxc_*` crates will now compile), then retries full generation.

Compress `a | (b | c)` to `a | b | c` and `a * (b % c)` to `b % c * a`.

Follow-on after #15593 and #15600. Use `// prettier-ignore` comments in test fixture files to prevent them being formatted, where formatting would break the test.

#15603) #15565 made `oxc_ast_tools` depend on local workspace versions of various crates. Add those crates to the watch list for "AST Changes" CI task, so if changes are made in them, `ast_tools` codegen will run to ensure generated code has been updated to reflect those changes. In particular, this will prevent generated code getting out of sync when changes to minifier affect the generated code.

Add comments on `extend` methods explaining why they're OK to use in `createContext`.

codspeed-hq · 2025-11-11T20:08:34Z

CodSpeed Performance Report

Merging #15608 will not alter performance

_{Comparing 11-11-refactor_language_server_provided_commands_and_provided_code_action_kinds_for_toolbuilder_ (46900d2) with main (fc439ed)¹}

Summary

✅ 37 untouched

No successful run was found on 11-10-refactor_language_server_move_tools_definitions_to_backend_ (a8f4156) during the generation of this report, so main (fc439ed) was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

camc314 and others added 30 commits November 11, 2025 01:26

docs(maintenance): oxlint/oxfmt release docs updates (#15570)

e92276d

test(formatter/sort_imports): Fix tests to match with original (#15577)

c9591ea

Just updated wrongly copied tests.

docs(linter): Fix a typo in the docs for react/no-is-mounted. (#15575)

fd58aea

Also add an additional test from the upstream plugin.

perf(formatter/sort_imports): Use Vec::with_capacity for `next_elem…

cd31cc1

…ents` (#15579)

perf(formatter/sort_imports): Precompute import metadata (#15580)

128e186

- Before: Compute metadata for sort inside of `sort_by()` - After: Collect these data before `sort_by()`

feat(oxfmt): Print nothing for default(write) mode (#15583)

99823ad

Fixes #15555

chore(ci): Add apps/oxfmt/package.json to versioned_files for `ox…

1b61334

…c_release.toml` (#15585)

release(crates): oxc v0.97.0 (#15582)

98585f0

ci(release_apps): fix zizmor error (#15589)

6a982f6

ci(ast_tools): run "AST Changes" CI task when CI workflow file changes (

ec66eb4

#15591) Add path to CI workflow file to the watch list for "AST Changes" CI task, so the task runs if the workflow is altered.

ci(ast_tools): remove dprint tool from "AST Changes" CI task (#15590)

e389b47

We used to use `dprint` in `oxc_ast_tools`, but #15064 switched to `oxfmt`. Remove `dprint` tool from the "AST changes" CI task.

test(linter/plugins): remove dprint-ignore-file comments from test …

3eefa15

…fixtures (#15593) We don't use `dprint` any more to format JS/TS. So remove defunct `// dprint-ignore-file` comments from test fixtures.

feat(docs): improve rendering of oxlintrc schema markdown (#15571)

1741204

feat(linter/no-callback-in-promise): add support for timeoutsErr op…

6cd0b5f

…tion (#15507) Closed #15178

feat(minifier): rotate binary expressions to remove parentheses (#15473)

68703b9

Compress `a | (b | c)` to `a | b | c` and `a * (b % c)` to `b % c * a`.

style(linter/plugins): use prettier-ignore in test fixtures (#15602)

74033bd

Follow-on after #15593 and #15600. Use `// prettier-ignore` comments in test fixture files to prevent them being formatted, where formatting would break the test.

refactor(linter/plugins): add comments on Context#extend (#15604)

2de35be

Add comments on `extend` methods explaining why they're OK to use in `createContext`.

github-actions bot added A-transformer Area - Transformer / Transpiler A-codegen Area - Code Generation A-cfg Area - Control Flow Graph A-isolated-declarations Isolated Declarations A-ast-tools Area - AST tools A-formatter Area - Formatter labels Nov 11, 2025

Sysix mentioned this pull request Nov 11, 2025

feat(language_server): add run_server helper for CLI tools #15609

Merged

Sysix removed request for Dunqing, camc314, leaysgur and overlookmotel November 11, 2025 20:10

Sysix marked this pull request as draft November 11, 2025 20:10

Sysix closed this Nov 11, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comments

refactor(language_server): `provided_commands` and `provided_code_action_kinds` for `ToolBuilder`#15608

Sysix commented Nov 11, 2025 •

edited

Loading

Uh oh!

codspeed-hq bot commented Nov 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Uh oh!

Comments

Conversation

Sysix commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codspeed-hq bot commented Nov 11, 2025

CodSpeed Performance Report

Merging #15608 will not alter performance

Summary

Footnotes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Sysix commented Nov 11, 2025 •

edited

Loading