6 ms·

Run anywhere without installing locally, just like nodemon. I npm install everything locally, never globally, and use npm run script to easily execute (and cha

Run anywhere without installing locally, just like nodemon. I npm install everything locally, never globally, and use npm run script to easily execute (and chain) stuff. Am I in the minority?

dragonshed 8y ago
I can count with one hand the number of things I install globally. Everything else is local.
- kn8 8y ago
  Same, the global pkgs I always have installed are: * nodemon * npm-check * ndb * serve * webtorrent-cli * jetpack
  - colecut 8y ago
    Hello. My name is Inigo Montoya. You killed my father. Prepare to die.
kn8 8y ago
Nah, I think installing locally is more common and often recommended. But I personally like the convenience of executing ad hoc bits of js on my laptop using `node` or `nodemon`. Why not the same for browser javascript? E.g. you could do something like: cd ~/Desktop/foo npm i somepkg echo console.log(require('somepkg')()) > index.js jetpack And now you're running some pkg in the browser, to try/test it out. That's what the use case for this feature really is. For real apps, I install it locally as well or else a breaking change in the future could cause issues.
- e12e 8y ago
  No language has this down, but there's an environment manager (pip, rustup, rbenv..) that try to do all, and avoid the need to handle more than one "magic" session in your bashrc(etc): "asdf": https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf Now, a few new languages do come with pretty decent "virtual env" thingy-s , but most stumble for a few years. So far (past year) I've been pretty happy with asdf. Mostly use it for ruby and node - but also rust and golang, lisp, Java and ocaml (mostly as a "consumer" of various cli tools, and/or toy projects.
  - type0 8y ago
    asdf is fine for small cli tools, but it fails way too often when you need something that requires more configs and system level integration, so then you end up installing nvm, rvm etc anyway.
  - GlennS 8y ago
    Another way to do this is to install Nix and direnv (and/or Emacs direnv-mode), then include a `use nix` statement in the .envrc file inside your project root. Then, when you `cd` into your project directory, your environment with all its dependencies appears. However, there are some downsides to this magical future tech: + Nix is hard to learn. + Not compatible with the standard environment managers for each language. https://github.com/direnv/direnv https://github.com/direnv/direnv https://nixos.org/nix/ https://nixos.org/nix/
    - e12e 8y ago
      Interesting. I've been considering nix, but wasn't aware of direnv. Should be a sensible combination.
nickthemagicman 8y ago
I do this with app specific stuff. Only general utilities do I install globally.
rhacker 8y ago
The only thing I install globally is yarn. It just helps make things more reproducible to install everything locally (except yarn because we don't use npm directly).
timdorr 8y ago
Even better, use npx (bundled with npm): https://www.npmjs.com/package/npx https://www.npmjs.com/package/npx
topspin 8y ago
> Am I in the minority? No, you are not. The disconnect between actual developers that know better than to rely on global pollution and the silly READMEs and blog posts that prescribe it is an interesting phenomena. It's also gone on long enough that I feel a little shouting is in order.
fiatjaf 8y ago
I always assume everybody uses pnpm, which is the best disk/bandwidth saver utility every written.
hiccuphippo 8y ago
WebPack gives me errors when I npm run it. I need to directly run ./node_modules/.bin/webpack which leaves a bad taste in my mouth.
- turdnagel 8y ago
  Add a script in your package json that just runs `webpack`. Then you can run e.x. `npm run webpack`
TheLudd 8y ago
Modules that are part of your build, tests and npm scripts should be installed locally so that any contributor can run npm install/yarn and the develop your project without any other need and they will also get the correct version of the module. Global installs are for modules that are outside your projects dev cycle. With that in mind, a module such as nodemon can be installed both globally and locally. It depends on the use case.

Run anywhere without installing locally, just like nodemon. I npm install everything locally, never globally, and use npm run script to easily execute (and chain) stuff. Am I in the minority?

dragonshed 8y ago

I can count with one hand the number of things I install globally. Everything else is local.

kn8 8y ago
Same, the global pkgs I always have installed are: * nodemon * npm-check * ndb * serve * webtorrent-cli * jetpack
- colecut 8y ago
  Hello. My name is Inigo Montoya. You killed my father. Prepare to die.

kn8 8y ago

Nah, I think installing locally is more common and often recommended. But I personally like the convenience of executing ad hoc bits of js on my laptop using `node` or `nodemon`. Why not the same for browser javascript? E.g. you could do something like: cd ~/Desktop/foo npm i somepkg echo console.log(require('somepkg')()) > index.js jetpack And now you're running some pkg in the browser, to try/test it out. That's what the use case for this feature really is. For real apps, I install it locally as well or else a breaking change in the future could cause issues.

e12e 8y ago
No language has this down, but there's an environment manager (pip, rustup, rbenv..) that try to do all, and avoid the need to handle more than one "magic" session in your bashrc(etc): "asdf": https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf Now, a few new languages do come with pretty decent "virtual env" thingy-s , but most stumble for a few years. So far (past year) I've been pretty happy with asdf. Mostly use it for ruby and node - but also rust and golang, lisp, Java and ocaml (mostly as a "consumer" of various cli tools, and/or toy projects.
- type0 8y ago
  asdf is fine for small cli tools, but it fails way too often when you need something that requires more configs and system level integration, so then you end up installing nvm, rvm etc anyway.
- GlennS 8y ago
  Another way to do this is to install Nix and direnv (and/or Emacs direnv-mode), then include a `use nix` statement in the .envrc file inside your project root. Then, when you `cd` into your project directory, your environment with all its dependencies appears. However, there are some downsides to this magical future tech: + Nix is hard to learn. + Not compatible with the standard environment managers for each language. https://github.com/direnv/direnv https://github.com/direnv/direnv https://nixos.org/nix/ https://nixos.org/nix/
  - e12e 8y ago
    Interesting. I've been considering nix, but wasn't aware of direnv. Should be a sensible combination.

nickthemagicman 8y ago

I do this with app specific stuff. Only general utilities do I install globally.

rhacker 8y ago

The only thing I install globally is yarn. It just helps make things more reproducible to install everything locally (except yarn because we don't use npm directly).

timdorr 8y ago

Even better, use npx (bundled with npm): https://www.npmjs.com/package/npx https://www.npmjs.com/package/npx

topspin 8y ago

> Am I in the minority? No, you are not. The disconnect between actual developers that know better than to rely on global pollution and the silly READMEs and blog posts that prescribe it is an interesting phenomena. It's also gone on long enough that I feel a little shouting is in order.

fiatjaf 8y ago

I always assume everybody uses pnpm, which is the best disk/bandwidth saver utility every written.

hiccuphippo 8y ago

WebPack gives me errors when I npm run it. I need to directly run ./node_modules/.bin/webpack which leaves a bad taste in my mouth.

turdnagel 8y ago
Add a script in your package json that just runs `webpack`. Then you can run e.x. `npm run webpack`

TheLudd 8y ago

Modules that are part of your build, tests and npm scripts should be installed locally so that any contributor can run npm install/yarn and the develop your project without any other need and they will also get the correct version of the module. Global installs are for modules that are outside your projects dev cycle. With that in mind, a module such as nodemon can be installed both globally and locally. It depends on the use case.