hiding implementation and extreme optimization is no need for top level but core libs.application usually grow faster than core libs.You need to separate the two parts, ’cause: What I’m thinking is to keep the excessive strategy for core libs but not the top level of application. We’re working on an application with some core libraries inside it now. the compression strategy, is not to mangle the properties, it will be easy for developers to focus on creating phase, not optimizing one. I cannot tell everyone, please comment /* prettier ignore */ on every object with string format properties, that’s not cool.įrameworks like react, publishing lots of CLI tools to setup a application fast. Unfortunately, prettier will wipe out the quotes on string format key. and non-key properties cannot be invoked in computed format, like obj.Ĭommunity has brought a cool thing, prettier, for auto formatting your code. ![]() you have to keep some properties in string format. Will it finally adopt this feature? Don’t know. Future of Minifyīabel has published its own minifier called babel-minify, without support mangling props yet. Leverage terser-js will make that process easier, terser first then babel. Since maintainer decide not to maintain uglifyjs anymore, terser-js came out. We’re done! Simpler only support es5.Īt around Aug 2018, uglify’s job pass to another successor. This guy will apply all presets and plugins we specified in babelrc on the output. Once we got partial es6+ code, uglify-es could mangle it correctly without brokens.Īfter uglify’s own part is down, webpack will feed assets to another plugin, babel plugin. we don’t transform classes at the beginning. Then? What we do is compiling it first with only couples of es6+ plugins like transform-computed-props. nested properties had been mangled in wrong way. Look at variable c, every key is compressed as a same one. simple, right? name it demo.js (function () ![]() a very simple class Apple with 1 getter and 1 prototype method, then invoke the method and getter in a closure. That’s too hard for compiler - “I can’t dope out everything!”. Define a method on a class could be dynamic, add a property to a class is the same. ![]() and it’s too dynamic that compiler is hard to guess the full structure during the parsing work. Why Mangling Properties May Break Your Code?Įmmmm… JavaScript is never a static language from the birthday till now, maybe ever. then we back to the old school: enable mangle property options. However, sometimes you got to hide the implementation details, that you have to compress it more. now more developers choose to use ordinary compression on their code, things work fine. Today UglifyJS is welcomed, (even the maintainer gave up the work on it right now) more frameworks and libraries are mixed up, network traffic get better, developers don’t want to handle that stuff again. like native APIs, some properties from response result, etc. people are careful on maintaining the whitelist for all the keys you wouldn’t want to be mangled. once you got enabled advance compression, that will bring a lot breaks on production code. 2 ~ 3 years ago, it’s commonly that we use google closure compiler to handle javascript code compression process.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |