Closed ljharb closed 7 years ago
I don't really feel like there's much of a point in this feature: npm run <script>
does this job well enough, for one. If you want -p
, you can still do $ npx -p <pkg> npm run foo
, too.
Performance won't really be any different here, either: when using the -c
option, npx actually executes an extra npm child process to fetch all the necessary configurations to emulate run-scripts properly. In the end, this method would be much slower than a plain npm run
call.
Gotcha - the two main benefits I can think of are performance, and that node installations that lack an npm
entirely could still run scripts - the latter has been a concern of node core, but isn't mine; and it sounds like the former wouldn't work out. Thanks for the reply!
@ljharb There's work going on right now to extract the lifecycle script subsystem out of npm and put it in a standalone library. Keep an eye on https://github.com/npm/lifecycle.
Essentially, I'd like to be able to do
npx --script=foo
, and have it do the same thing asnpm run foo
, but much faster since it wouldn't have to bootstrap all of npm :-)The way I envision it working is that it would read "scripts.foo" from package.json, use the contents as the
-c
, and then proceed normally from there.-p
, and the other options, would continue to work as expected.--script
would of course have to be mutually exclusive with-c
.Theoretically,
npm run x
could even proxy out directly tonpx --script=x
, lightening up npm itself :-DI tried to take a crack at building it, but it's probably better to start with the issue and get some pointers if you think this is a good idea.