Configurable node version

[oleasteo]

(moved from oxc-project/oxc#16994 (comment), as it's already possible in VSCode)

It would be nice to be able to configure the used node version / binary path for oxlint / oxfmt execution inside IntelliJ.

Background

In our project, we are bound to an LTS node version; that is the version we deploy with. We're in the process of adding a second "edge" node version for development tooling like linter / formatter. Mainly due to the new node requirement for newer oxlint / oxfmt versions. But we think it's a good idea to have the two node versions decoupled in general, to not lack behind on future dev tooling features.
Thus, we want to use the LTS node for tests and simulation, while using the edge node for linting / formatting / building.

Our directory structure will look like this:

/package.json // engine: edge
/.oxlintrc.json
/.oxfmt.jsonc

/app/package.json // engine: LTS
/app/tsconfig.json
/app/src/...

We manage different node versions with n.

This way, using oxlint / oxfmt works perfectly via cli. But the IntelliJ Project node.js version currently needs to be set to the edge version, which is "wrong" as it's used for node language assistance as well (w/o any way to specify another version for that). It would be preferable to have the "main" IDE project engine set to LTS node and configure edge version for the tools that are supposed to use it. Esp. oxlint / oxfmt.

🎄

[nrayburn-tech]

All of the current settings are intended to be shared for a given project. A Node.js exe path isn’t something that is typically shareable.

This may work for corporate environments that enforce a specific standard such as only using one tool and it is always installed in one location. However, for all other environments using this property would prevent the other settings from being committed and shared in a trivial way.

I’m not saying that this couldn’t be made to work, but I don’t think it will work well for most users and I’m not sure it’s something I want to introduce.

For now, I’ll leave the issue open and if there are other users that want this feature then please give it a thumbs up.

[nrayburn-tech]

Your scenario of LTS/Edge may just be an example, but does oxfmt or oxlint use any features that are not available on a currently supported Node.js version? I would be surprised if that’s the case and would be something worth looking into.

https://nodejs.org/en/about/previous-releases
https://github.com/oxc-project/oxc/blob/9348f10053ac72ba26524d799f4892ab2692cdbd/npm/oxlint/package.json#L33
https://github.com/oxc-project/oxc/blob/9cf10117e62a48394bfadb86dee2bfb3bd154b0d/npm/oxfmt/package.json#L34

[oleasteo]

Since I haven't ever shared my IDE configs in any team (sounds dirty to me, but that might just be preference), I cannot speak for those who do. But how would the "Languages & Frameworks > JavaScript Runtime" or "Languages & Frameworks > TypeScript" settings be considered in that shared settings use case? Both have a select for nodejs runtime.

In my case, yes, the "main" nodejs version is not supported anymore. However, it is operated on offline / VPN-shielded devices. So a lack of support is not a critical issue per se (hence lower priority on updating). Thus, using an 18.x "main" nodejs version right now doesn't work with oxlint/oxfmt in my case. I would expect that some teams will have similar requirements with low priority on updating nodejs, even if it's against best web practices.

[nrayburn-tech]

https://github.com/oxc-project/oxc-intellij-plugin/blob/main/sandbox/oxlint/custom-config/.idea/OxcSettings.xml is where we store our settings for Oxlint. There’s also a file for oxfmt. That file can be committed and shared between developers.

IntelliJ does have other settings that are not intended to be committed and shared, for example .idea/workspace.xml ( I believe that’s the name ) contains user specific information that you wouldn’t want to share. The setting you mention is likely stored in one of these files that aren’t intended to be shared.

VS Code and Zed both have a similar concept of shared project settings within the .vscode and .zed folders. I’m not as familiar with those, but I do know they exist and can be committed for a shared team configuration.

Using outdated Node.js versions is common, so your scenario isn’t surprising. It’s less common to try and use newer tooling on projects that must use older Node.js versions. Using an older Node.js version typically means you need to stay on the older tooling as well (and deal with all the problems that come with that unfortunately).

---

Like I mentioned before, I’ll leave this open and see if anybody else is interested in the feature. My personal opinion is that it’s not something worth introducing because it doesn’t really align with what other tools in the ecosystem are doing to my knowledge. If I’ve got that wrong and this ability is common, then I’m more than happy to reevaluate.

[nrayburn-tech]

@Sysix @camc314 any thoughts on this?

It probably isn’t too difficult to implement, I’m just not sure it’s something that should be done.