Can't install latest version of npm globally

[mareksuscak]

I'm unable to install and override the global npm package at all (i.e. replace with the latest version). I'm getting File name too long error for many packages. This is a deal breaker for me.

Global installs are also incredibly slow which was already reported here - #46

Other than that, it's a great idea to have a single version manager. Thanks for all the efforts.

PS: nodenv handles this well and global installs are fast - might be a great source of inspiration

OS: High Sierra w/ APFS

[danhper]

Hi, thanks for reporting.
I managed to reproduce the issue locally. The issue seems to be that we have a npm binary in nodejs/installs/VERSION/bin and another one in nodejs/installs/VERSION/.npm/bin. The second should take priority but does not.
I do not have much time to work on this right now, so help is very welcome.

[mareksuscak]

@tuvistavie no problem, happy to contribute, can you give me some pointers on where to start and briefly describe how the solution should work? i'm not familiar with the codebase ATM so that would be super helpful, thx for looking into this!

[danhper]

@mareksuscak Thank you!
The problem is in the reshim command, which does not rewrite the shim as it already exists.
https://github.com/asdf-vm/asdf/blob/master/lib/commands/reshim.sh#L59
However, as the existing shim is pointing to nodejs/installs/VERSION/bin and the new one should point to nodejs/installs/VERSION/.npm/bin, it does not work as expected.

However, after thinking about it, this is a little more complicated than it looks.
As long as we stick with a single version, we would simply need to rewrite the shim, but for a case where a version of NodeJS should use .npm/bin/npm and another does not have .npm/bin/npm but only bin/npm, I do not see any clean way to handle this with the current interface.
@asdf-vm/maintainers Any idea on how we should handle this?
By the way, why are we using .npm as NPM_PREFIX and not simply the root of the installation?

[dipnlik]

cd ~/.asdf/installs/nodejs/8.8.1/lib && npm i npm looks like a decent workaround for now, but I'm not sure of the side effects, if any.

[jschank]

I have this problem too. What if:

1. There were an 'asdf exec' sub-command, that essentially did the switch to the current install directory, and ran the passed command?
2. There were an 'asdf upgrade ' command, supported by the plugins that would manage this sort of task?

I'm using the work-around for now. But it will be easy to forget this, by the time I need to do it again.
:)

Thanks

[adsteel]

Running into this issue as well. MacOS High Sierra 10.13.1.

FWIW I experienced this issue on Nodenv, first. I switched to ASDF (a good excuse to switch, anyway) to fix it, but the problem persisted.

[joemsak]

The workaround didn't work for me, nodejs 9.9.0

[andrewthauer]

Perhaps it might make sense to automatically install npm (e.g. npm i -g npm@[shipped-version]) when a new version of nodejs is installed? Then if the plugin's list-bin-path is swapped from bin .npm/bin to .npm/bin bin the reshim will correctly write npm to use .npm/bin. It would also guarantee all versions of nodejs have npm installed as a node_module in .npm/bin.

This would likely work for anyone starting fresh (with the updated plugin). However, since shims are not recreated if they exist, it would require someone that has an older setup to manually fix it up (i.e. remove the previous shim). I suppose it would also break if someone uninstalled npm global for some reason as well.

[mareksuscak]

@andrewthauer that sounds totally reasonable, at least as a temporary fix

[andrewthauer]

I think the only way to avoid running into some of these outlier cases there must be a conditional check somewhere. In order to do this it's likely going to require some sort of plugin customization hook support in asdf core since shim generation has very limited knowledge about the plugin language (as it should not).

I think this might be a possible solution to the problem ...

Provide an optional plugin hook that is used by the get_executable_path function (which is called by asdf-exec). This would then need to check if the plugin (e.g. nodejs) has an alternate command path for the specified shim command (e.g. npm). For instance the nodejs plugin would use .npm/bin/npm if it exists or fallback to bin/npm if not.

[andrewthauer]

I ended up created a couple of PR's to address this #74 (which will work if accepted). I had a look at how nodenv works and handles this. There is actually no special handling at all. The root cause actually lies in how the node version install is setup by the asdf-nodejs plugin:

A stock node binary install has a lib/node_modules directory which contains npm with the command linked to bin/npm. The asdf-nodejs plugin also does this. However the difference is the plugin also adds an .npm/lib/node_modules & .npm/bin directory for any globally installed packages. In the case of npm this ends up creating 2 different locations for the npm command.

nodenv on the other hand installs global packages the root lib/node_modules directory, which seems to be the standard location (further investigation is warranted). This means there is only ever one instance of any global package (including npm). The actual fix, might just be adjusting how node versions are installed to correspond to what seems to be the stock pattern.

[andrewthauer]

It turns out the NPM_CONFIG_PREFIX is the crux of the issue here. Removing the exec-env file fixes this and #57. Removing it will make the plugin behave like nvm & nodenv by default and avoid the issue altogether.

@tuvistavie, @Stratus3D, @HashNuke - I personally can't think of a strong reason to support NPM_CONFIG_PREFIX in this plugin can you?

There still would be the issue of pre-existing installs and shims that would likely cause breaking changes if it's removed completely. Given that the existing shims would be using the prefix, it seems like it could be difficult to address without breaking changes.

[rstacruz]

I added a workaround that works for now (as of 2018-05-24): #57 (comment)

This is not ideal, but it should at least make it work to get you out of possibly-insecure legacy npm versions.