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.

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

consider to support "nvm" in node-debug extension #25386

Closed
weinand opened this issue Apr 26, 2017 · 7 comments
Closed

consider to support "nvm" in node-debug extension #25386

weinand opened this issue Apr 26, 2017 · 7 comments
Assignees
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality on-testplan
Milestone

Comments

@weinand
Copy link
Contributor

weinand commented Apr 26, 2017

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:

2017-04-26_10-49-42

(for lengthy discussion see see #1895)

Opinions?

@weinand weinand added debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality labels Apr 26, 2017
@weinand weinand self-assigned this Apr 26, 2017
@frehner
Copy link

frehner commented May 16, 2017

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
Copy link

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
Copy link

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

@weinand
Copy link
Contributor Author

weinand commented Aug 7, 2017

@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?

@weinand weinand added this to the On Deck milestone Aug 7, 2017
@denkristoffer
Copy link

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

n is another common node version manager.

@weinand weinand modified the milestones: On Deck, December 2017 Dec 8, 2017
@weinand
Copy link
Contributor Author

weinand commented Dec 22, 2017

@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):

2017-12-22_18-07-59

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.

@roblourens
Copy link
Member

Great! I pushed the same fix.

@weinand weinand closed this as completed Dec 22, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Feb 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality on-testplan
Projects
None yet
Development

No branches or pull requests

6 participants