Should binaries be removed from IDE extensions?

[laurentpayot]

Sincce version 1.36, oxfmt and oxlint binaries were removed from the IDE extensions:

Given that all IDEs now use --lsp, we can "safely" remove the binary
to reduce the published package size by half.

This forces you to install oxfmt and oxlint dependecies separately (for now in dev dependencies of your projects, global install seems not to be working for some users). See #17744 for more details.

What do you folks think of this removal ? 👍 or 👎 this removal below so we can have a little poll.

[laurentpayot]

As I said in #17744, to me this removal sounds more like a bug than a feature. Pure IDE tools like linting and formatting should not interfere with a project dependencies. I dont care about IDE plugins size. I do care about having to add more dependencies. Even dev dependencies.

[rubenferreira97]

I support removing the bundled binaries to decrease package size and ease the release process.

I view global installs as a valid replacement for bundling. They keep the package light while still allowing for a system-wide configuration. Pointing the extension to a global binary feels like a cleaner solution than bundling one inside the extension itself.

For projects, I personally find relying on devDependencies to be a more robust workflow because it establishes a single source of truth. When extensions bundle their own binaries, we risk version mismatch where the IDE reports different errors than the CI/CLI because they are running different versions. Ideally, the IDE should reflect the dependencies defined in the project.

A note on the poll structure: There is currently a contradiction between your title and the body text that might skew your results.

Title: "Should binaries be included?" (👍 = Yes, keep them)
Body: "What do you think of this change [removing them]?" (👍 = Yes, remove them)

You might want to clarify which question people are voting on to ensure you get accurate data.

[laurentpayot]

@rubenferreira97

You might want to clarify which question people are voting on to ensure you get accurate data.

You are right. I changed the title and reformulated the question.

[lazharichir]

At this point, I don't really have a preference, I'd just want oxlint and oxfmt to "just work" as I've been battling binary not found for both on VS Code with 1.39.0 for an hour. Probably because I use npm workspaces.

[danciudev]

Most of us who use the extension have oxlint installed, we just want it to work. If we reduce the size that's a positive bonus.

[nrayburn-tech]

A couple of things to consider.

Shipping a binary with the extension or using a global install can result in different results between the CLI and the IDE experience. This can only be resolved by ensuring you use the same version with the CLI and the IDE. The easiest way to do this is to manage it with your package manager.

Not all plugin systems allow shipping the executable with the plugin in a system in an OS specific way. Meaning, extensions may have to ship each supported binary for the user to download when they’ll only ever use a single one. (You don’t need the Windows binary on a Linux install for example.) This would cause a pretty significant installation size for the plugin which is a factor to consider.

A possible solution is to download the binary that you need at runtime. The problems that come with this is that it means you may need to download and store the binary in two places (an IDE location and your project location). This can also make offline usage more difficult as you need to download the binary for CLI usage and for IDE usage. This also makes the IDE plugins more complex and likely results in a different experience depending on which IDE you use, which can be confusing. There’s also a consideration about authentication. If you use a private NPM service, then you likely need to supply credentials. Users would need a way to supply the credentials to the IDE for how to download along with the NPM URL. Alternatively, the IDE could use the package manager that you have setup locally. This would require configuring the IDE to specify which package manager is in use, but it eliminates the URL and credential issue.

There are definitely different approaches to solve this issue. My opinion is that shipping the plugin without the binary is the right approach. Most users will have oxfmt/oxlint installed as a dependency within their project already to support CLI usage and plugins can reuse this installation. The IntelliJ plugin has used this approach since the beginning and I’m not aware of any problems from it. However, that’s a different ecosystem and isn’t an exact comparison to VS Code.

---

I do completely agree that the experience should be better and I think the Oxc team would love to make it better. I believe that most of the Oxc team has Rust experience and I’m not sure if they have any IDE plugin development experience (don’t quote me on that), so they are doing their best to learn some of this on the fly while maintaining multiple IDE extensions (IntelliJ, VS Code, and Zed are the ones I know of but there’s a few others I think).

[Boshen]

Sorry for the inconvenience.

I recommend using project-local installations for consistency. We previously encountered much larger issues where IDE and CLI behaved differently.

[A81N9]

I think extensions should integrate binary. Just like prettier extension.
For example, how should I use oxfmt sometimes when I use vscode to open a single file instead of a workspace?

I feel the right thing to do is that extensions still integrate binary, and when the workspace has no local dependencies, use extended binary.

[rubenferreira97]

For example, how should I use oxfmt sometimes when I use vscode to open a single file instead of a workspace?

You can install oxc globally via npm -g, then set the executable path in the extension settings one time. If oxc is configured in a workspace, that version is used instead.

[gulshan]

I think when a project-local installation is not found, the extension should search for the workspace and then the global install of oxc. And use them if found. This can at least be an option, if not the default behavior.

[camc314]

We should do this here: #18007

[rubnogueira]

I'm on the team - don't ship the binary with the extension. This will make the extension slimmer and not tied to a specific version.

Currently I have both binaries installed globally on my machine for some specific projects that don't use the oxc project, but I also have projects that already use both oxfmt and oxlint.

This gives better control over what specific version we want to use since we can control the executable version over package.json.

Imagining that in a specific codebase we ran into some regression with oxlint, we can lock the version to the previous version, having greater control over which version to use.

"oxc.path.oxfmt": "node_modules/.bin/oxfmt",
"oxc.path.oxlint": "node_modules/.bin/oxlint",
"oxc.path.tsgolint": "node_modules/.bin/tsgolint",

Since we can specify in the workspace or user settings the path of the binaries, I'm 100% on that team.

EDIT: While I understand that potentially makes adoption harder, maybe the onboarding can be more direct, like "oxfmt/oxlint not found in the workspace or globally, do you want to set it up?". I don't remember what the current approach is.

[infalmo]

Atleast provide the option to let the extension auto-download the binaries?

[PleaseDont]

I think 'Extension' means that it should provide out-of-the-box functionality.

[Profesor08]

As I understand it, the main issue is that the extension and the globally installed CLI use different binaries/versions. Someone with the same setup expects them to behave identically?

But I don’t understand one thing: why would anyone expect the same result when using different versions? That makes no sense at all.

I believe such changes should not be made just to accommodate these rare and unreasonable edge cases. This kind of change breaks the experience for the vast majority of users.

Right now, with no working binary available, I can’t even format a single file.

To make it work, I have to install the tool globally, somehow figure out the correct paths, and then manually configure those paths somewhere in the settings. Any time the path changes (new install location, different machine, updated Node version, use of nvm, etc.), everything breaks. And any extension update - or even a minor update - can make it incompatible again, forcing me to go through the whole setup once more. Again and again.

P.S. Biome has exactly the same issues, and that's why I had migrated to oxc - to finally get rid of them.

P.P.S. TypeScript binaries are shipped with built in vscode extension. And there are no issues with them. TypeScript just works.

[trymeouteh]

Please include oxc inside the extension to allow the user to always have oxc available. If there is no oxc package in the project, it will fallback and use the oxc in the extension.

Would also go nicely with oxc-project/oxc-vscode#9 or to look for a oxc config file in the home directory.

[jonas783]

(I'm an idiot but...can we at least add a line or two in the extension details section to explain that binaries are not bundled?)

[YKDZ]

I fully support 👍 removing the bundled binaries from the extension.

My perspective is that formatting and linting are logically integral parts of a project. Developers must have complete awareness and control over the specific tools and versions applied to their codebases. This is best achieved through explicit dependency declarations (e.g., in package.json), rather than having the toolchain obscured behind an automatically updating VS Code extension version.

Relying on project dependencies guarantees that the behavior of the linter and formatter remains strictly consistent across all environments—whether it's in CI pipelines, local development, or collaborative team workflows. Conversely, bundling binaries inevitably leads to frustrating, hard-to-debug discrepancies where the IDE behaves differently from the CLI, or where team members see different results based on their local extension updates.

In my view, binaries installed via devDependencies should serve as the single source of truth, or at the very least, the default source.

A great example of this philosophy in practice is nx. Even when invoked via a globally installed CLI for convenience, nx automatically detects and delegates execution to the local version locked in the project's dependencies. This smart design proves that mature toolchains recognize the absolute necessity of respecting local definitions to guarantee deterministic outcomes.

root ➜ /workspaces/cat (main) $ nx --version
Nx Version:
- Local: v22.3.3
- Global: v22.4.5

[laurentpayot]

But how to ensure devs will actually install the plugin? 😄 😉

[YKDZ]

I 100% agree with your concern about adoption and the out-of-the-box experience for individual devs. If a new user installs the extension, sees an error, and has to manually figure out npm commands, they will likely just uninstall it. That friction is real and needs to be addressed.

However, bundling binaries inside the extension is a flawed technical solution to this UX problem because it destroys the deterministic environments required by professional teams (where the IDE must strictly match the CI/CLI version).

Furthermore, in professional engineering environments, extension adoption is driven by the codebase, not manual discovery. When a dev opens the repo, VS Code automatically prompts them to install it. For team collaboration, this is essentially zero-friction.

To solve the onboarding friction for individual developers trying out Oxc in a single file without a package.json, I highly recommend adopting a Fallback & Auto-Download strategy:

If the extension boots up and cannot find a local (or global) binary, it simply shows a VS Code notification:
"Oxc binary not found. Would you like to [Download & Install Automatically]?"

This completely preserves the zero-config, plug-and-play onboarding you correctly advocate for, while keeping the extension package lightweight and ensuring enterprise codebases don't suffer from stealth version mismatches.

[mubaidr]

Extensions should be 'plug-and-play.' Without bundled binaries, the friction of setup increases significantly. If the user is forced to manage the binary themselves, the value of having an extension over a simple CLI command or npm script is greatly diminished.

If no binaries included then might as well contribute just a task/ command to vscode to run oxfmt.

[Profesor08]

If dev really cares about consistency, he should have all required configuration for his project, to make extension to work in the way as he wants. Extension will pick binaries from node_modules, and will use them. In case when there is no configuration files, it will use it's own, built-in binaries.

In case, when user should install binaries manually, extension must handle every case (it is impossible), to just to find binary. It is interesting, how it will work on windows when node vesions are managed by nvm or fnm

[A81N9]

I think the best practice is to do something like https://github.com/prettier/prettier-vscode.
The extension contains binaries and provides global configuration.
For use in single-file and non-workspace projects (without package.json).

Just like this:

"prettier.printWidth": 100,
"prettier.semi": false,
"prettier.singleQuote": true

[tinywaves]

I think a plugin should provide an out-of-the-box experience. Sometimes we edit isolated or standalone files, and having formatting work immediately is very useful. Especially considering that oxfmt already supports many languages — and may support even more in the future — these standalone scenarios will likely become even more common.

So in my view, the most reasonable design would be:

1. The extension contains binaries and will first try to locate a local binary, searching upward through parent directories.

2. It should support global configuration via VS Code settings, similar to Prettier, for example:

   {
     "oxc.fmt.rules.singleQuote": "xxx"
   }

3. The current behavior of "oxc.fmt.configPath": "" seems to concatenate the value with the current working directory.
   For example, if set to:

   "oxc.fmt.configPath": "~/.oxfmtrc.json"

   it ends up resolving to:

   /Users/username/foo-project/~/.oxfmtrc.json
   

   This default behavior feels somewhat unintuitive.

[anthonylaflamme]

I work in a weirdly setup "monorepo", where our root has no package json. Then I have a frontend and a backend that both have oxlint. I don't want to use vs code workspace nor I want to setup oxlint at the root nor I want to setup an oxlint path to the binary (that could diverge unless we stamp the version and are strict on it).

So I do feel the extension should include the binary as first class citizen. So it's just a plug and play and can read config files.

[ivancuric]

I also use mise to install oxc globally, which the extension can't find.

[infalmo]

Have made a PR to support this (partially) - oxc-project/oxc-vscode#150

[infalmo]

Have implemented a working version here: https://github.com/infalmo/oxc-vscode/tree/allow-oxlint-cmd. Much simpler to configure, supports most requirements and works well with monorepos. I use it all the time.

[tinywaves]

Any updates?