Automatically use current node from environment

[thernstig]

Hi!

I am using a project such as https://direnv.net/ to set my environment per directory. I.e. if I change into various project directories where I do coding, I can have an .envrc (or .env) file that gets automatically loaaded on dir change. There are many other similar projects (autoenv etc.).

In regards to this, eslint.runtime is explained like:

  // The location of the node binary to run ESLint under.
  "eslint.runtime": null

Looking at other issues here, it seems I need to set this manually? My question is then, is it not possible for it to load the current Node.js version from the environment if not setting this? I also feel the description for the config above should be more verbose, actually mentioning that it needs to be set if that is not the case.

In addition, I am not sure how to work with actually setting eslint.runtime. This is specific per project. I cannot set it in my user settings, as that would affect all my projects. I also cannot set it the workspace settings, as different users might install it in different locations.

It does seem VS Code properly supports loading the environment: https://code.visualstudio.com/updates/v1_52#_improved-terminal-environment-handling-linux-macos

[dbaeumer]

Have you simply tried to use node as the value. However that needs node to be available through your environment.

[thernstig]

@dbaeumer That did fix it. I wonder if that should not be the default really rather than the built-in one?

[dbaeumer]

No, since it would require users to install node to have ESLint support. The direction of VS Code is to work out of the box without any additional executable installs.

I will close the issue.

[thernstig]

@dbaeumer But "eslint.runtime": "node" cannot be set in the user settings in VS Code. It is grayed out and hovering over it reports This setting cannot be applied in this window. It will be applied when you open local window..

I agree with that direction, but if a node is found in the environment, then I think it should opt to use that instead of the builtin. I.e. the config eslint.runtime could have a new config basically having an effect like "use environment node if exists otherwise fall back to built-in".

I would have liked to set such a config in my user settings. That is much more intuitive for me, as I have control of my environments node but I do not have control over the built-in node.

[dbaeumer]

You mean having an auto value for the runtime setting?

[thernstig]

As your answer was very short, I can only guess what you mean, but I guess yes. Was the problem description in my last post not good enough? The essence is that using a built-in node version is not ideal if I already have one in my environment. And I cannot set "eslint.runtime": "node" in the user settings (see error above).

[thernstig]

I can create a new, better issue for this if wanted with a better description. Will give it a go later.

[dbaeumer]

@thernstig can you describe your setup a little bit more. Since I can set "eslint.runtime": "node".

[thernstig]

Hi @dbaeumer sorry for the late reply! There are two separate issues as I see it.

1. I cannot set "eslint.runtime": "node" in my USER settings. It is greyed out and gives the text This setting cannot be applied in this window. It will be applied when you open local window. when hovering. See here:
   

2. If I have a node in my environment, this plugin should use that rather than the built-in one. It is confusing for users to have to configure "eslint.runtime": "node" in settings, as e.g. if you run ESLint via command line, it will not use the same version by default and ESLint via command-line does not bundle any node. There are other reasons.

This issue is about 2) so maybe 1) should be a separately submitted issue.

[dbaeumer]

@thernstig regarding your comments:

1. this is because you are using some sort of remote setup (WSL, docker, ...) so you have to configure the setting in the corresponding remote user settings file. Best open the settings UI and look for the corresponding remote tab (in the screen shot below it is the WSL Ubuntu tab

2. we can't since this would result in code execution without user confirmation which according to VS Code's model should be avoided.

[thernstig]

@dbaeumer

1. I am using remote ssh, and I do not have those options (as can be seen in the picture). But I could configure it in the Workspace settings. I'd note that to the same extent I am using Python where this works perfectly fine for the same scenario via e.g. "python.pythonPath": "${workspaceFolder}/.venv" in my User settings.
   EDIT: I can however set in the settings GUI. Maybe this is an oversight in VS Code in that it should show even an empty (WSL or ssh) settings file in the JSON editor? Still, it works fine in Python to set the environment in User settings.
   

2. VS Code Python is adding support for this, see Details on the A/B experiment removing python.pythonPath support vscode-python#12313 i.e. they are adding support to auto-discover the Python env see Select a Python Interpreter without modifying the workspace's settings.json vscode-python#2125

So for Python a) I can set it in my user settings in a similar fashion b) they are working on auto-discovering the "python" enviroment (and thus binary).

What am I missing? Would this not also be the ideal case for a user in regards to point 2?

[dbaeumer]

Python is different in the sense that VS Code doesn't ship any Python. But even if Python discovers the environment it must ask for user configuration as well since this is what the VS Code model asks for. Since VS Code ships with Node we use that version as the default since it avoids the user confirmation step for most users.

[thernstig]

I will try to rephrase this feature request a bit. I will just focus on one thing then, that would solve most problems.

Feature request
Is it technically impossible to let users set "eslint.runtime": "node" in their user settings, which will work both in local and remote (ssh, wsl, container)? If not techincally impossible, why is it a bad idea? (I do not get the answer about Python for this part, as bundled or not, Python still supports an equal setting for this in user settings i.e. "python.pythonPath": "${workspaceFolder}/.venv".)

What benefits would this bring?

• Many of us move between machines, containers, ssh hosts, wsl, into many projects. Setting "eslint.runtime": "node" everywhere, all the time, is time consuming, easy to miss etc. Setting it in user settings would mean I as a user could opt into always using what is in the environment for the current project, no matter where it is located.
• Features such as const fs = require('fs/promises'); do not work in the bundled version, since the bundled version is older than what most projects use (version 14 or later). It is also not great to use another version than the environment (project) has in combination with ESLint plugins such as https://www.npmjs.com/package/eslint-plugin-node

[dbaeumer]

Having one setting "eslint.runtime": "node" in the user settings that is used for remote setup is currently not possible due to limitation in VS Code. Declaring node as the default value is nothing I can do due to the fact that users needs to confirm the use of executables.

Hope that explains it.

[thernstig]

@dbaeumer it is great explaining why things are what they are, and that is appreciated because you have vast knowledge. So thumbs up!

I do feel though that considering this is a feature request, we are talking about what we want in the future. What should we request in the VS Code repo to get this working then?

Aside: Why is "python.pythonPath": "path/to/python_binary" working just fine in user settings? Looks exactly like the same case.

[dbaeumer]

@thernstig you need to request a change to the settings scope management in the VS Code repository that a setting with scope machine-overridable is available even if only defined in a user setting file.

Regarding Python: I don't know. I guess they might use a different scope which doesn't support machine-overridable. But that scope is the recommended scope for settings that point to executables.

[thernstig]

Done: microsoft/vscode#119183

[dbaeumer]

@thernstig thanks!

[thernstig]

@dbaeumer I just noticed this when using the Settings UI (I usually use the JSON mode):

The info there is incorrect then?

[dbaeumer]

It should read in user/machine setting.

[dbaeumer]

Fix in the description.