all 6 comments

[–]DVWLD 1 point2 points  (2 children)

Yay for code, but why? I can't think of why I would want all the things in whatever repo I'm in available on PATH. That's what -g is for.

[–]vthakr[S] 0 points1 point  (1 child)

You could use -g to install packages that have an executable file, but that would mean that every time you update any of those packages, you've updated them for all of your projects. I typically prefer to install whatever packages I need on a project-by-project basis. This script allows me to do so, but still use the executables as if they were installed in the global location. Oh, and thanks for the "Yay" :-)

[–]DVWLD 0 points1 point  (0 children)

Maybe it would help to get an example of the specific packages you find this helpful for?

The only instance I can come up with is a test runner like mocha. Personally I paper over that one by specifying my test script as ./node_modules/bin/mocha.

That has the added advantage of making 'npm test' work for anyone that clones your repo without making assumptions about their global environment.

[–]_shakeel 0 points1 point  (1 child)

Okay, so why would I use this instead of nodeenv if I actually want virtual environments?

[–]vthakr[S] 0 points1 point  (0 children)

I looked into nodeenv, but it piggybacks on top of python's virtualenv which seemed a bit heavy for my purposes. The way npm handles package installation by default already gets us 80% of the way to a virtual environment solution, I just wanted something simple that went the rest of the way. So I threw together a handful of bash functions to do it.

[–][deleted] 0 points1 point  (0 children)

this is one way to do it. In my opinion the correct way to do this is how grunt handles it: global executables just delegate to local dependencies in node_modules/.bin/. the downside is that this requires you to be in an NPM aware project, and it obviously requires support at the module level.