Benefit of this over npm run?
garygreen opened this issue · comments
The readme seems to allude to the main difference being that it will automatically install the needed dependencies to run a command. Wouldn't the dev dependencies etc already be listed and installed in package.json, anyway? It would be good if the readme can be a bit more clear in what the actual benefit of using this has over just using npm i && npm run
It's about running a package that is not part of any repo or project.
npx executes a package without having to install it or leave any residue on the system. It also works in the way you described similarly to npm run, but is much more flexible than just that.
I use it for things that I don't want globally installed nor part of a specific project. I've used it for parsing and generating documentation from markdown files for distribution to customers. That's an occasional task for which the package being part of the repo would significantly bloat things, but I also don't want to install the package globally on any machine I might be using. There's one package in particular I've used that would slow down npm i by a factor of 10x, so I left it out of the dependencies. It takes forever to run using npx (if I don't have it installed globally), but I can just let it go in a separate terminal and work on other stuff. If it slowed down npm i, it would be a blocker.
There's a particularly good tutorial on egghead.io about npx that I believe is at least partially free. I'm using and describing here just a small fraction of its power, but still appreciate it (and fingers crossed that the project isn't abandoned: #223.)
It sounds to me this library crosses over a bit with peerDependencies and devDependencies - except it installs only when you manually want it to. I question the complexity if this package when it has a lot of similarities when all your essentially wanting is a "throwaway" node_modules folder created with certain dependencies, on-demand. That's how I'm understanding the purpose of this project? Maybe I have a simplistic view of it though.
I think a lot of libraries could benefit from not listing huge unnecessary dependencies though, but again surely that's something that devDependencies and peerDependencies already solves pretty well?
I use npx to:
- use stuff that's not installed globally nor in my current folder tree
- run one-off commands
E.g., I'll use it to npx eslint --init a new project (that has ESLint as a dev-dependency), which is not a command that makes sense to have in my package.json scripts section.
I'll use it to npx eslint --init a new project (that has ESLint as a dev-dependency), which is not a command that makes sense to have in my package.json scripts section.
package.json ? I would argue it's the perfect place; just as you would commit your lint config file.
Of course the package is a dev dependency. But the script to init isn't.