Some code in Oxc repo is Cargo feature-gated - most notably all the code in `oxc_data_structures`, but also bits and pieces all over the place.
Currently, when using VS Code, Rust Analyzer only gives you jump-to-definition etc on code which is part of default features set. Code that's gated behind a Cargo feature is "dark" to RA. Ditto `cargo check` and Clippy which are run on save in VS Code. This makes working on feature-gated code slow and annoying.
This PR alters the default VS Code settings for the repo to run Rust Analyzer, check, and Clippy within VS Code with the equivalent of `--all-features`. This matches what `just check` / `cargo ck` and `just lint` do.
This also has a beneficial side effect:
RA shares `target` directory with the terminal. In a workflow where you're using RA and also running `just check` / `just lint` regularly (which agents do), previously each would compile separately with different settings. Now they all use the same settings, so share the same build artifacts. This reduces both compile/check/lint time, and reduces the speed at which `target` directory grows.
Remove the Prettier related stuff from the conformance, which is purely aimed at JS/TS.
Instead, `oxc_formatter_tests` manage Prettier's test fixtures along with Oxfmt.
Prevent Rust Analyzer indexing and tracking files in directories it
doesn't need to (`node_modules`, submodules).
Rust Analyzer doesn't obey `.gitignore`, so the thousands of files in
these directories all get indexed, unless explicitly excluded.
This makes Rust Analyzer's startup faster and makes it use less memory.
Working on my MacBook Air which has limited memory, I've found Rust
Analyzer grinds the machine to a halt when have multiple worktrees going
in different VS Code windows. This appears to help a bit.
## Summary
- Removes `editors/vscode` directory - code has been moved to
https://github.com/nicholasrice/oxc-vscode
- Removes `tasks/vscode_docs` crate (no longer needed)
- Removes CI and release workflows for VS Code extension
- Updates `editors/README.md` to point to the new repository
- Cleans up references in `.gitignore`, `justfile`, `oxc_release.toml`,
`oxfmtrc.jsonc`, `oxlintrc.json`, and `pnpm-workspace.yaml`
closes#17484🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
All files except `.rust` files can be formatted with `Oxfmt`, so set up the Oxc extension as the default formatter for VSCode, and explicitly set `rust` to use `rust-analyzer` for formatting.
This will ensure that oxfmt is applied automatically on all JS/TS files
that are edited by the developer when working on the oxc repo. The hope
is that this avoids some unnecessary extra `just fmt` runs and
autofix.ci commits.
This PR implements a second language server connection only for `oxfmt`. Currently, it still uses the shipped `oxc_language_server` binary for formatting. When defining a custom `oxc.path.oxlint` (or `oxc.path.server`), it will start the search process for `node_modules/.bin/oxfmt` or uses `oxc.path.oxfmt`.
This should be **not** a breaking change. When `node_modules/.bin/oxfmt` should be required for formatting, the `ConfigService.useOxcLanguageServerForFormatting` must not be modified. I would love to wait for the correct search implementation for `.node_modules/.bin/oxlint` before breaking the server detection (and probably removing the shipped server too).
### Default / with `oxfmt` installed:
Using the internal language server (once)
### with `oxc.path.oxlint`:
Using the oxlint path server for linting.
Searching for `oxfmt` inside `node_modules/.bin`
### with `oxc.path.fmt`:
Using the internal language server for linting.
Using `oxc.path.fmt` binary
<img width="257" height="233" alt="grafik" src="https://github.com/user-attachments/assets/0776920d-76cd-49cf-9357-fae2ea4a0eb8" />
<img width="193" height="238" alt="grafik" src="https://github.com/user-attachments/assets/c3b2670d-559e-4d0a-96b2-b420e868e1a1" />
<img width="174" height="258" alt="grafik" src="https://github.com/user-attachments/assets/63f9a265-cae9-4971-9c21-86adeacaf35d" />
Improve the experience of launching the VS Code extension for development purposes. Now it will build it for you automatically when launching the editor extension, rather than you needing to build it yourself.
We could also maybe keep a launch setup that doesn't do this alongside this one, if others prefer using that workflow.
See this video for the workflow of building+launching this from the debug menu in VS Code:
https://github.com/user-attachments/assets/738368d4-88fd-424b-ab96-4b1cfed38491
Previously, we were wasting some time creating a `Vec` at runtime with the lintable extensions, which is all of the JS/TS extensions plus other frameworks extensions like `.vue`. Now, we precompute this as a static string slice at compile time. This also ensures that we are using the same extensions list between `oxlint` and the language server too. Theoretically this is a very minor perf win possibly?
I noticed that both just and typos have official vscode extensions, so I
added them to the recommended extensions list.
The `EditorConfig.EditorConfig` extension was present in the
devcontainer configuration but not in the recommended extensions list,
so I added it there as well.
Changes the default VSCode build command to run `cargo fmt` and `cargo
test --no-run`. This can be easily run with `Cmd+B` (or `Ctrl+B` for
Windows users).
1. Use `log::info` to print some informantion which we would want to
display in release mode,
2. Add config to switch back `debug` log level in development mode.
related: #688 .
There are some unfinished things that need to be finalised by Boshen.
1. Official icon and description for the package.
2. Publishing strategy ( It's probably not a good idea to use
`package.json` as a probe to publish extension, as there's too much
vscode configuration coupled to it, a git tag like `vscode_v0.0.x` might
be worth considering ).
3. License for the extension.
overlookmotel