[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 :)