-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rfc: Command to add a script to package.json #41
Conversation
In the bikeshedding: I think this should be |
Can it somehow be prevented from being invoked from postinstall scripts? otherwise it seems like a new attack vector. |
@ljharb That would just add a new script to the {
"scripts": {
"install": "npm add-script postinstall \"something evil\""
}
} But that strikes me as no more dangerous than: "scripts": {
"postinstall": "something evil"
}
} That is, it's not safe per se, but I'm not sure if I see how it's a new attack vector. |
I guess it feels like anything you can do with npm is more privileged/trusted than anything you can do without - and adding a new script to the package doing the installing is what I’m concerned about. |
More potential bikeshed ideas, which I am very much not pushing for, but want to make sure get logged here. What if we extend npm run start # runs the scripts.start
npm run start "node server.js" # runs node server.js, with env.npm_lifecycle_script="start"
npm run start "node server.js" --save # same as above, but save to script.start The hazard here is that npm exec node server.js
npm exec --save-script=start node server.js This would also bring some of the functionality of The safest and easiest approach is to add an |
@isaacs I thought the name |
Just one npm CLI pedantic note: in npm In this case, "set the script" is the action, so it should be a positional argument, not a config flag. But yes, |
The wording for the warning message could be documented (or bike shed). My proposal was:
|
Thing I wish existed. No opinion on the implementation or any of the bikes.