Mid-script Args

[forrest-rival]

• nps version: latest
• node version: latest
• npm version: latest

Problem description:

Since we're improving on npm scripts, it would be awesome to be able to pass script args somewhere in the middle of the script.

e.g. passing an environment to a script like ENV={env} webpack --config webpack.config.{env}.js

Suggested solution:

Would love to begin a discussion about potential approaches and challenges. My first thought is to use template literals for interpolating script args into scripts in order to form the string that finally gets executed.

[kentcdodds]

Sorry, this project is pretty much in maintenance mode until someone else steps up to be a maintainer. I don't use this much and so I don't have time for writing on it.

[forrest-rival]

No worries, thanks for the heads up!

[forrest-rival]

@kentcdodds just out of curiosity, what would you guess is the effort level for maintaining this project? I've never maintained an open source project, but potentially interested or might know someone that would be.

[kentcdodds]

It's all in how much you want to put into it. I haven't done much with this project in about a year and it's still getting 11k downloads per month 🤷‍♂️

[forrest-rival]

Cool, I'm going to get some input from my team at work, think about it and get back to you.

[Mehuge]

Can't you just do

process.env.ENV = 'production'

with the script: 'webpack --config webpack.config.${ENV}.js'

[forrest-rival]

lol, I think you may be right; I'm going to feel dumb if that works 😂

[wmertens]

Maintainership could be managed like styled-components - anybody that has a PR merged gets write access if they want, via a bot, and then the top-level maintainers cut releases every once in a while.

That said, the solution offered by @Mehuge is indeed the way to do it ;)

Here's how I manage debug and env settings in package-scripts.js:

process.env._dbg =
	'*,-babel*,-express*,-send,-body-parser*,-morgan,-compression,-puppeteer*'

const DEBUG = `DEBUG=\${DEBUG:-$_dbg}`

const webpack = (cfg, {prod, watch, browser, minify} = {}) =>
	[
		`NODE_ENV=${prod ? 'production' : 'development'}`,
		browser && 'BROWSER=y',
		minify && 'MINIFY=y',
		`webpack --config ./lib/webpack/webpack.config.${cfg}.babel.js`,
		(watch && '--watch') || '--bail',
	]
		.filter(Boolean)
		.join(' ')

const scripts = {
	default: 'nps dev',
	dev: {
		default: `nps dev.debug`,
		plain: `nps build.dll dev.runPlain`,
		debug: `nps build.dll dev.runDebug`,
		runPlain: webpack('server', {watch: true}),
		runDebug: `${DEBUG} ${webpack('server', {watch: true})}`,
	},
	...etc
}

module.exports = {scripts}

[kentcdodds]

Maintainership could be managed like styled-components - anybody that has a PR merged gets write access if they want, via a bot, and then the top-level maintainers cut releases every once in a while.

This is how it works, except without the bot.

The fact is, nobody I've given commit rights to has taken up the responsibilities of a maintainer.

[wmertens]

The fact is, nobody I've given commit rights to has taken up the responsibilities of a maintainer.

:-/

I can do PR reviews and merges for nps and nps-utils. What are your expectations for maintaining? What kind of changes are ok to do/reject?

[kentcdodds]

Because I'm not using the project anymore, I'm not the one to say. I'd just ask that maintainers follow server and get feedback from users before making large changes.

Once someone takes the role of maintainer and proves they can handle it, I'll personally bow out and grant release rights.

[wmertens]

Ok, works for me. Sign me up. Out of interest, how come you're no longer using the project, is it no longer your domain or do you do things differently now?

…

On Mon, Aug 13, 2018 at 4:38 PM Kent C. Dodds ***@***.***> wrote: Because I'm not using the project anymore, I'm not the one to say. I'd just ask that maintainers follow server and get feedback from users before making large changes. Once someone takes the role of maintainer and proves they can handle it, I'll personally bow out and grant release rights. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#177 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADWlkFzl0R2e9U0c2W8ntEBkox8knxRks5uQY9bgaJpZM4Ub1aK> .

[kentcdodds]

Now I write a CLI that encapsulates most of the scripts that my projects need: https://blog.kentcdodds.com/automation-without-config-412ab5e47229

Go ahead and start making PRs/helping in issues and I'll give you commit access :)

[wmertens]

Ah yes in nps I don't have a PR yet but in nps-utils I do.

[mreschke]

Here is a scenario I would love this "mid-script args" to solve. I am using Nrwl NX monorepo with tons of angular apps inside. I want to create an NPS shortcut for each app to get into the NG Angular cli for that app. I want to type nps wiki.ng to use any NG command in the context of the wiki app. For example to generate a new component in the wiki app I woulf run nps "wiki.ng generate compoment xyz". This is equivalent to running ng g generate compoment --project=wiki-app.

This could work if I could only tell nps WHERE to place the "quoted paramaters". By default nps just places them at the END of your command. But that does not work because --project=wiki-app must be AFTER generate compoment xyz.

NPS shouldn't assume I want my "quoted params" at the end. It should let me pick where they get injected. Something like this

script: "ng %params% --project=wiki-app"

Now the params of compoment generate xyz are added inline.

[wmertens]

@mreschke the problem is encoding the given parameters.

Since nps always expects to generate shell code, I propose that the literal "$@" is replaced with the shell-quoted arguments, $* with the arguments as-is, and $1 etc with the shell-quoted positional argument.

Now, currently the only way to pass arguments is to call nps "name arg1 arg2" so $@ and $* will be the same. If that is changed to be nps name arg1 arg2 then there can be a difference (see #139)