consider to support "nvm" in node-debug extension

[weinand]

Many users are managing their installed node versions via "nvm".
But it seems to be difficult to make VS Code use the node version installed by "nvm".

To simplify this we could directly support "nvm" in node-debug launch configurations e.g. by adding an optional "nvm" attribute that takes a version specifier:

(for lengthy discussion see see #1895)

Opinions?

[frehner]

I like the idea; would it be possible to pull the version from an .nvmrc file instead? That way the launch config wouldn't need to be updated for each project, and people already used to following the convention of putting the version in an .nvmrc don't need to do anything different.

[saintwinkle]

I'm using n, also facing the issue you've mentioned above: #1895 .

In my situation, for reference, node path usually can be found in ~/.n/bin/node, while npm in ~/.n/bin/npm.

[nijikokun]

Would probably be best to have something like "platform": "n" or "platform": "nvm"

[weinand]

@nijikokun I do not really see the value of "platform".
What other values besides "nvm" would be possible for "platform"?
And a "nvm" attribute would be still needed to specify the version?

[denkristoffer]

What other values besides "nvm" would be possible for "platform"?

n is another common node version manager.

[weinand]

@roblourens A first cut of this feature will be available in the next Insiders.
Supported are "nvm" and "nvm-windows". The attribute to specify the version is runtimeVersion.
Before you can refer to a version of node, the version must be installed elsewhere, e.g. a nvm install 7.10.1 from the command line.

As an example here is the launch config for the "legacy" version of the cluster feature:

		{
			"type": "node",
			"request": "launch",
			"name": "Cluster (legacy)",
			"runtimeVersion": "7.10.1",
			"program": "${workspaceFolder}/test.js",
			"autoAttachChildProcesses": true
		}

And here the output (which shows that node from the nvm folder is used despite the fact that node 8.9.1 is my default version):

Most of the implementation lives in the shared extension code and just massages the launch config.

However, I had to make one change in node-debug (and you might want to do the same in node-debug2).
Previously findOnPath(...) did not consider the env vars specified in the launch config. So if a modified "PATH" would have been specified in the launch config, node-debug would not have used that to lookup the "node" runtime executable. I think this was clearly a bug, so fixing this makes sense independent from the nvm feature.