Specify options to uglify via angular-cli
pleerock opened this issue · 16 comments
Is there any ways to specify uglify options via angular-cli ? uglify strips class names which is not acceptable for me because Im relying on class names in my code.
From what I see in webpack-build-production there is no way to specify custom options. Process of building apps for different environments can be pretty dynamic depend depend on use case, I hope angular-cli will cover all such scenarios in the future, otherwise there is small point in using it. Also I think having all options in a single angular-cli.json cant cover all cases, despite my personal favorite of simplicity, because build process is non trivial sometimes, and should be and angular-cli should be flexible
We're not looking at adding this option, no. It's a pretty granular setting and does make bundles larger.
I've had that problem myself, mind you, as have others (see http://stackoverflow.com/questions/29310530/get-the-class-name-of-es6-class-instance).
I wouldn't say it's a bad practice to rely on it, but I think it's very brittle. Even if you don't mangle names in your app, library authors cannot rely on it because they can't control how people uglify their code.
@filipesilva It would be really useful to be able keep the correct class names at runtime in certian dynamic scenarios (for instance if what component to display is decided at runtime based on a string value provided by an external entity such as a workflow engine etc.).
@filipesilva, please, add this possibility to specify uglify options
It's not well known, but whitespace removal and symbol mangling accounts for 95% of the size reduction in minified code for most JavaScript - not elaborate code transforms. One can simply disable compress to speed up Uglify builds by 3 to 4 times.
I think it would still be nice to be able to specify some uglify options. I like @smknstd am really interested in being able to turn off compression. We did that in our prior webpack build before moving to the CLI and it made it almost 3 times as fast. We got the idea from a post from slack which quotes the author just like @smknstd did.
It would be nice to have a flag for that at least as having our build server take 3 times as long doing builds for 5% improvement is definitely not ideal.
If people are interested in other UglifyJS options it seems like perhaps a viable option would be to handle UglifyJS options like the proxy.conf.json and allow fine tuning?
Me too, in our project mangle breaks the production build.
+1
+1
We solved our problem by copying @angular/cli into it's own directory and then including it in package.json like:
"@angular/cli": "file:angular_cli",
Hope this helps someone in the future. It's not ideal, but at least it works.
@filipesilva it would be great to have at least "regex" property for mangling exposed. It would allow us to keep class names we absolutely want to keep.
flux-action-class relies on class names to avoid creating constants for action types in our ngrx apps and uses class names instead. Absence of this tuning forces us to use the workaround mentioned by @atteeela, which is not very pretty.
@filipesilva don't you think developers should have as much freedom as they want?
Btw, terser has even better option for my case 'keep_calssnames'
@pleerock I created a small custom builder for that. Hopefully we won't have to use it for a long time and Angular teams adds this functionality at some point to their default builder.
@hansl @filipesilva @clydin @alan-agius4 @Brocco any chance you could re-visit this one?
As to the bundle size 'keep_classnames' increased it only by 4-5% in my app, which is not much. It could be even less since 'keep_classnames' allows RegEx as a value to keep only those classes we need.
We're not looking at adding this option, no. It's a pretty granular setting and does make bundles larger.
I've had that problem myself, mind you, as have others (see http://stackoverflow.com/questions/29310530/get-the-class-name-of-es6-class-instance).
I wouldn't say it's a bad practice to rely on it, but I think it's very brittle. Even if you don't mangle names in your app, library authors cannot rely on it because they can't control how people uglify their code.
@filipesilva What is the point of limiting user options? You can add the default values you think work better, but not allowing developers to change them at their own risk sounds like a bad statement.
There are libraries that relies on reserved words and are quite well used (https://github.com/SAP/chevrotain for example). Not being able of using them in an Angular project it's a pity :(
Can you please revisit your decision? This would be such a great improvement!
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.