-
Notifications
You must be signed in to change notification settings - Fork 365
Description
#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:
- https://marketplace.visualstudio.com/items?itemName=charliermarsh.ruff
importStrategydefault isfromEnvironment. - The Python extension by default loads the venv from environment.
- https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode does as well.
- etc. etc.
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?