Simplify npm run scripts by sending in params

[debloper]

We are using yargs, which makes arg-parsing really simple in JS code.
npm run <scriptname> -- -arg="value" allows to pass over args to scriptname.

With this in hand, we can simplify the ~70 different scripts that we preset, down to about 20.

For example, "build:aot", "build:aot-min", "build:dev", "build:docker", "build:prod", "build:prod-aot" & "build" all these steps become one simple build script in npm scripts which takes params to specify prod, dev etc. All these umbrella scripts will have necessary defaults, so that calling them without any param also has its purpose (like it does with npm run build even now).

This will keep the package.json lean and clean, while not missing out on any functionality. It will also abstract the build details from package.json itself. It will be agnostic to changes in the build procedure and addition/removal of new flags/params. It will soft-force us to document all the params used/available for a certain script (build or watch or test or clean etc.), and that's a good thing.

[dgutride]

A lot of us use webstorm for running the npm scripts - if I have to specify arguments, it will make it much more difficult to run the application when developing. I prefer the shorthand approach instead of leaving it to developers to figure out what all available flags are. Please do not make this change.

[debloper]

@dgutride haven't used webstorm, but you mean to say you can run npm run build:dev but not npm run build -- --type="dev" or npm run build -- --dev?

I don't see any such limitations on webstorm's docs, can you please post links where it's detailed?

UPDATE: from JetBrains docs, passing args, env_vars etc are supported to run npm scripts with webstorm's workflow. Any problem with using the NPM Run/Debug Configuration that makes it happen?

[dgutride]

@debloper - you can run with any arguments, but many of the IDE's make it really easy to run the npm scripts by just double-clicking. You'd have to set the properties in a separate configuration step to make them always use them (and they aren't as discoverable by users)

[joshuawilson]

The structure of these scripts is very common. If you look at a couple of examples you will see they are the current norm.

• https://github.com/angular/quickstart/blob/master/package.json
• https://github.com/angular/angular-cli/blob/master/package.json
• https://github.com/AngularClass/universal-sitegen/blob/master/package.json

I did find others using the approach you suggest. I will consider it.

My first 2 thoughts regarding all of the architecture designs/decisions are:

1. ease of use / adoption
2. performance / stability

It is very important that anyone can join us and see that we have code that is done the Angular way, in the UI. At this point, we are still following their example. If we find that we can improve then we should consider that.

[joshuawilson]

If you reason is to "keep the package.json lean and clean" then that is not enough for me based on the last comment.
What has driven you to look into these things. What pain point is it creating for you. Mostly this stuff should be invisible to much of the team.

[joshuawilson]

@debloper did you want to continue this or should we close it?

[debloper]

@joshuawilson sorry, this one got overlooked last week (or I forgot to click the comment submit button).

I'm going to implement this for planner, depending on that experience you may wanna make a call whether it makes more sense or not (honestly, it's just an idea, and I'd like to discover the real-world implications too - on paper it definitely looks good to me). Till then, it's up to you whether you wanna keep this open for revisit or close it off for now. It's cool either way.

[joshuawilson]

I'll close it, it you want to reopen it later go ahead.