Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Prefer to use node from environment #1727

Open
thernstig opened this issue Nov 3, 2023 · 5 comments · May be fixed by #1977
Open

Prefer to use node from environment #1727

thernstig opened this issue Nov 3, 2023 · 5 comments · May be fixed by #1977
Labels
feature-request Request for new features or functionality help wanted Issues identified as good community contribution opportunities
Milestone
Backlog

Comments

@thernstig
Copy link

thernstig commented Nov 3, 2023 •
edited
Loading

#1596 (comment) mentioned:

I would only use a node version different the one the come with VS Code if you need to (e.g. using a eslint plugin that requires some special node features)

@dbaeumer Why is the recommendation to use the one that comes with VS Code?

Most other linters and VS Code extensions I am aware of defaults to using the one "from environment".

Examples:

It makes more sense to me at least. Each project, old or new, comes with a specific Node version. Imagine you work in multiple open source repositories. Most have a .nvmrc or a .node-version file. If I jump around between these, the Node version and thus implicitly the ESLint features changes depending on this.

To me the best solution would be to do like Ruff, where you fall back to the built-in one if you cannot find one from the environment:

importStrategy fromEnvironment Strategy for loading the ruff executable. fromEnvironment picks up Ruff from the environment, falling back to the bundled version if needed. useBundled uses the version bundled with the extension.

Could this be considered?
@thernstig thernstig mentioned this issue Nov 3, 2023
Closed
@dbaeumer
Copy link
Member

dbaeumer commented Nov 6, 2023

To not break any existing users this would need to go behind a setting. However there is already a setting to make it the default which is "eslint.runtime":"node". I am open to add support to fall back to the shipped version if this points to a non existing Node version.

@dbaeumer dbaeumer added the feature-request Request for new features or functionality label Nov 6, 2023
@dbaeumer dbaeumer added this to the Backlog milestone Nov 6, 2023
@thernstig
Copy link
Author

@dbaeumer even though"eslint.runtime":"node" can be set, this feature request is about changing the default to use the Node from environment (i.e. setting it to "eslint.runtime":"node"). Rationale explained in the original post.

I just think it makes far more sense, and cause far less confusion for users. Most projects worth its salt also run linting in CI, where you would (almost) always use the node from enviroment. There is no concept of a "built-in" there.

As such, for VS Code and the ESLint extension to mimic this, the default should be to get it from env in VS Code as well, to avoid users having to always configure "eslint.runtime":"node" in the VS Code workspaces settings (.vscode/settings.json).

To change the default obviously need some deprecation period/warning and a way for users to migrate. So that is something to figure out.

@runspired
Copy link

runspired commented Nov 21, 2024 •
edited
Loading

It's already surprising to find that this extension defaults to vscode's node version, but doubly surprising that the answer is we're supposed to know to opt-in to the expected default by setting a poorly documented setting with a name that seems unrelated.

That said, I don't think the setting works at all: my env is using node 22, setting "eslint.runtime": "node", in settings.json and restarting the eslint server it still is using node 20. The setting does not function as expected at all either, it results in using the default system node version instead of the node version used by the project.

Not using the environment's node leads to eslint not loading its configuration successfully due to mismatched node version expectations.

@dbaeumer dbaeumer mentioned this issue Nov 21, 2024
Closed
@dbaeumer
Copy link
Member

@runspired pointed out that we should also consider using node from the workspace / environement (if configured) instead of using the global node.

@wagenet
Copy link

wagenet commented Feb 5, 2025

I'm running into the same issue as @runspired and would love to see this resolved.

@wagenet wagenet linked a pull request Feb 5, 2025 that will close this issue
Open
@dbaeumer dbaeumer added the help wanted Issues identified as good community contribution opportunities label Feb 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature-request Request for new features or functionality help wanted Issues identified as good community contribution opportunities
Projects
None yet
Milestone
Backlog
Development

Successfully merging a pull request may close this issue.

Let the server determine cwd on its own wagenet/vscode-eslint
4 participants
@wagenet @runspired @dbaeumer @thernstig