[danabramov]

We're using Backbone+React so this may not be applicable.

However...

“You can separate your dev and production build pipelines to improve dev speed, but that’s going to bite you later on.”

In my experience, you must separate dev and prod pipelines. It has never bitten me because I make hundreds dev (local) and dozens kinda-prod (staging server) builds a day.

For dev builds, Grunt just compiles LESS but doesn't touch the scripts so there is literally no delay there. In dev environment, we load scripts via RequireJS so there is no need to maintain a properly sorted list of scripts too.

For production, we concat them with grunt-contrib-requirejs with `almond: true` so RequireJS itself is stripped out completely. Production build takes time (10 to 15 seconds; we're also running Closure Compiler), but it's never a problem.

Even adding JSX (Facebook React) compilation didn't cause a slowdown for dev builds because grunt-contrib-watches compiles them on change and puts into a mounted directory.

[sqs]

Yes, we did use separate dev and prod pipelines when we used AngularJS. (We used https://github.com/ngbp/ng-boilerplate.) It took 2-3sec for the dev build (most of which was taken up by recess) and 30-45sec for the prod build (primarily JS uglification). However, probably 5-10 times we deployed a broken site because either 1) the LESS compiler changed the order of our CSS rules or 2) we used AngularJS DI syntax somewhere that ngmin couldn't handle. We fixed the issues and added better linting, but it's still one more thing to think about (and the theme of this article is that it was death by a thousand cuts, not one big show-stopper).

[awinder]

I understand how this could be really frustrating. We solved this problem (well, we never really had it, but we solved the ability of this problem to come up) by having a suite of unit and functional webui tests. Combined that with a CI environment that runs these tests and creates builds only when the tests pass. Ngmin can be a little flakey if you get into fringe situations but deploying broken code is a testing problem, not a toolset problem.

[danabramov]

This clarifies things. I'm not familiar with Angular so thanks for sharing the perspective.

[vladgur]

Im curious which DI syntax couldnt be handled by ngmin?

I made it a rule to use the square bracket notation for angular DI and that obviously takes care of any minification issues.

[sqs]

For us, the most common case was non-square-bracket DI syntax in the "resolve" values of Angular UI-Router[1] route definitions.

[1] https://github.com/angular-ui/ui-router

[vladgur]

good to know. Im sticking to my square-bracket syntax :)