Global installs extremely slow

[davewasmer]

It seems that doing any npm install -g is an order of magnitude slower with asdf-nodejs vs. a standard npm install.

My guess is that it is coming from the post install hook the seems to run on every dependency and every nested dependency for global installs. The post install hook seems to invoke bin/get-bin-names.js for each package, which just parses package.json to find bin files to shim. I'm guessing a big chunk of that time is spent starting up a node process for each package.

I'd suggest we either:

• convert get-bin-names.js to a bash script that greps through the package.json to find the bin files (given the narrow acceptable values for the bin property in a package.json, grepping seems like it might be possible, or
• convert bin/postinstall.sh to node and consolidating it with bin/get-bin-names.js, so we can avoid the hit for starting up a node process for each package

Happy to PR the latter approach (the former might stretch my bash-fu skills a bit) if there's any interest.

[mareksuscak]

I'm also 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.

Created a separate issue to track work #56

OS: High Sierra w/ APFS

[danhper]

Sorry for the delay here.
The postinstall script indeed runs for every nested dependency, making install very slow.
Right now, the postinstall hook simply runs asdf reshim nodejs, but running this for every single dependency seems like a lot of overhead.
@davewasmer Can we manage to avoid starting up a new process for every single dependency?
Thank you for your help.

[davewasmer]

@tuvistavie I've since moved on from asdf unfortunately, so I no longer have time to devote to a PR here. But I would suggest one of the two options I described above.

[Stratus3D]

I'm experiencing this today. Very painful. While I have not addressed this issue I did address something related: c8f4518. The reshim command works better if a version is set.

[webhive]

Any progress with it?

[igelstorm]

I just encountered this problem. The code seems to have moved on since the original post - bin/get-bin-names.js is no longer run in the postinstall script, only asdf reshim, but this, too, is slow to run, which adds up to a lot of time when installing packages with a lot of dependencies.

As a blunt workaround, I commented out the line in the postinstall script that runs asdf reshim - i.e. in ~/.asdf/plugins/nodejs/bin/postinstall:

#!/usr/bin/env bash

# asdf reshim nodejs "$ASDF_INSTALL_VERSION"

I then ran asdf reshim nodejs <version> once, manually, after I was finished installing. I don't know if this approach has any unintended side effects, but it seemed to work for me, and might be useful to anyone else who has this issue right now and needs to get around it.

[igelstorm]

Some more insight into the problem: running asdf reshim nodejs without a version is a lot slower than giving it a version. It seems that the ASDF_INSTALL_VERSION environment variable isn't populated when the postinstall script is run on my machine, so it runs asdf reshim nodejs without a version number even though this clearly isn't the intended behaviour. I don't know nearly enough about asdf to know why this env var might be blank, so I don't think I can attempt to fix this.

[frnco]

I settled for using a different env var in the file ~/.asdf/plugins/nodejs/bin/postinstall

Switched from

asdf reshim nodejs "$ASDF_INSTALL_VERSION"`

To

asdf reshim nodejs "$npm_config_node_version"

There may be a way to call ~/.asdf/plugins/nodejs/bin/postinstall through asdf, kinda like asdf-exec, but I have no idea. Would still run for every single package though.

For limiting to a single reshim something like Custom Shim Templates would allow it, but I don't think it's worth it. I'd either stick with postinstall or drop auto-reshimming entirely and allow people to decide if and how they want to automate it.

[joemsak]

@frnco's suggestions appears to have worked for me

[daniel-nagy]

This is still kinda ridiculous for some packages. It takes almost 6 minutes to install the polymer-cli on my MacBook Pro.

time npm install -g polymer-cli

real	5m42.131s

[lnikkila]

^ I only started noticing this after updating to Node 10.14.1 from 9.11.2, using the latest version of asdf and asdf-nodejs. Not quite sure what changed. Rolling back to 9.x makes the installs fast again.

EDIT: I believe something changed between npm 5.6.0 and 6.1.0 that caused this to happen, Node 10.2.1 is fast but 10.3.0 is slow. I scoured through changelogs but didn’t spot anything suspicious...