npm install,build,test,publish a la Makefile

(Cyril Auburtin) #1

Proposing this shorter syntax to run a sequence of commands and scripts

it’s equivalent to npm install && npm run build && npm test && npm publish

It also unifies npm core commands and custom scripts, like yarn does, or like that bash function does too


n() {
	if [[ "$1" =~ $npmRegexp ]]; then 
		npm "$@"
		npm run "$1" -- "${@:2}"

(Kat Marchán) #2

NB: not unifying commands and scripts is a very intentional design decision. I consider that unification an extremely bad idea.

(Cyril Auburtin) #3

I guess your point is that you don’t want to mix npm core commands with user-defined ones, as some core commands could have important consequences. I partly agree, but commands like “start”, “install”, “test” are very ‘script’-like

I also really don’t want to type "npm run " every time I need to run an npm script, that’s way too many characters

Same reason for a sequence of npm scripts, I think the comma separated thing would make sense. I can just enhance my bash function for now, but it’s not practical when working in a team

(Kat Marchán) #4

Allowing that passthrough makes it so every time we add a new npm command, it becomes a breaking change. Because it can potentially break users that have been using their scripts through that. It’s the same as adding a plugin architecture, and it makes improving a CLI safely unnecessarily harder. run is not that many characters, and shells have fantastic alias systems.

(Cyril Auburtin) #5

For that I think it’s fine for npm to claim a new script name in the future, and forcing people (with a kind error message) using it to rename it, they are not so important, just names. What could happen? a broken CI at worse

(Kat Marchán) #6

It’s still a semver-major change. I’d rather have more freedom, and reduce confusion. This is an incredibly small amount of value at a relatively large long-term risk, so I just don’t see it being worth it at all. In the end, it’s the users that will hurt.