3 ms·
You never say why. I install tools I use often globally, use NPX for ad-hoc tools. NPX invocation is slightly slower and its more to type. Never had any problem
by tomashubelbauer 6y ago
You never say why. I install tools I use often globally, use NPX for ad-hoc tools. NPX invocation is slightly slower and its more to type. Never had any problems with either.
- Vinnl 6y agoThe why is that an upgrade of the globally-installed tool will apply to all projects using that tool. So if a breaking change in web-ext would require changes to your project, then you'll have to apply those changes to all your projects at once - unless they each have their own instance of it.
- tomashubelbauer 6y agoI see, I don't use any dependencies globally, but I do use global install for CLI tools I either invoke manually or use from scripts which I want to break if the tool CLI API changes so I can fix them and continue working on latest.
- mrozbarry 6y agoGlobal packages are harder to maintain. Let's say you installed foobar version 5 globally last year. This year, you're using a newer version of the foobar package that isn't backwards compatible. You install it globally, which replaces the old version 5. Now if you go back to the old project, your use of foobar is broken. Depending on the package, it might be fairly invasive/difficult to simply update. For myself, I always install global-recommended packages as dev dependencies. It can be a little painful, but it also means there are no special install instructions, and it _just works_ (tm).