Hacker News Reader

Comment by ronilan | Hacker News Reader

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?

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.

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

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.

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.

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://nixos.org/nix/

Interesting. I've been considering nix, but wasn't aware of direnv. Should be a sensible combination.

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

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).

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

Same, the global pkgs I always have installed are:

* nodemon

* npm-check

* ndb

* serve

* webtorrent-cli

* jetpack

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.

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

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.

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

> 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.

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

Reply on news.ycombinator.com