Optimize frontend. Part 2. We repair tree-shaking in the project on webpack

So, if you do not specifically repair, tree-shaking in the webpack does not work. Who does not believe, read my previous article . If you really want to fix it, then welcome under cat. There are several options that I could spy , to find come up with

Test code

All the experiments I did on two files that look like this:

// module.js class Wheel { pump(){ console.log('puuuuf');} } class Rudder { turn(){ console.log('turn');} } export {Wheel, Rudder} 

 // index.js import {Wheel} from './module.js'; class Car { constructor() { this.wheel = new Wheel(); } } const car = new Car(); car.wheel.pump(); 

The obvious option, the curve: uglify -> babel -> uglify

Code

In the comments to the previous article I was offered an obvious solution. If everything breaks down because babel interferes with the build and prevents UglifyJS from throwing out extra code, then why not run UglifyJS first and throw out extra code, and then later babel?

It was too lazy to write something specifically for the webpack, so I performed all the steps in the console via npm scripts.

I compiled the files from the example without the babel-loader and tried to skip through UglifyJS. UglifyJS fell. Well, do not understand the new javascript syntax!

It's okay, I thought, and dug up stewardess uglify-es . The problem is that babel doesn't know anything about minification, and the output is unminified code .

We'll have to chase UglifyJS again after babel.

I think that someone will probably use this approach, but I myself do not really like it.

Reasonable option: wait babel 7

Code

Do your clients use your code? Is he in production? If so, just schedule an update on the new babel after it is released. The disaster does not happen, because your application has been running all this time without tree-shaking.
If you are just starting to develop a project from scratch and at the same time are bold enough, you can already connect a test version. While you are working on your application, a new version of babel will be released.
In any case, babel is open-source, which means that you yourself can help him get out earlier.

Option radical: Rollup

Code

If you are not very bogged down in a webpack, it may not be too late to jump on the Rollup. In the case of simple applications and libraries, Rollup is a good choice.

Option radical and with crutches, but sometimes it works: typescript

Code

You can throw away the babel and compile your application with typescript. After all, we were promised that any javascript is already typescript;)
In the place where the #__PURE__ directive #__PURE__ typescript leaves the @class directive, and, as you understand, it doesn’t cost anything to write a loader that changes this very @class to what we need.

 module.exports = function(content) { return content.replace(/\/\*\* @class \*\//g, '\n /*#__PURE__*/ \n'); }; 

I think that you can come up with something with flow too. By the way, while I was writing, I thought that perhaps the babel could also be of some help now. Maybe one of you knows the answer?

Option radical, for fans of optimization: google closure compiler and advanced mode

Code

This is what I like best. To understand what I'm talking about, let's compare one by one, the best version of the bundle, resulting after compilation for:

 !function(n){function e(r){if(t[r])return t[r].exports;var o=t[r]={i:r,l:!1,exports:{}};return n[r].call(o.exports,o,o.exports,e),ol=!0,o.exports}var t={};em=n,ec=t,ed=function(n,t,r){eo(n,t)||Object.defineProperty(n,t,{configurable:!1,enumerable:!0,get:r})},en=function(n){var t=n&&n.__esModule?function(){return n.default}:function(){return n};return ed(t,"a",t),t},eo=function(n,e){return Object.prototype.hasOwnProperty.call(n,e)},ep="",e(es=0)}([function(n,e,t){"use strict";function r(n,e){if(!(n instanceof e))throw new TypeError("Cannot call a class as a function")}Object.defineProperty(e,"__esModule",{value:!0});var o=t(1);(new function n(){r(this,n),this.wheel=new oa}).wheel.pump()},function(n,e,t){"use strict";function r(n,e){if(!(n instanceof e))throw new TypeError("Cannot call a class as a function")}function o(n,e){for(var t=0;t<e.length;t++){var r=e[t];r.enumerable=r.enumerable||!1,r.configurable=!0,"value"in r&&(r.writable=!0),Object.defineProperty(n,r.key,r)}}function u(n,e,t){return e&&o(n.prototype,e),t&&o(n,t),n}td(e,"a",function(){return c});var c=function(){function n(){r(this,n)}return u(n,[{key:"pump",value:function(){console.log("puuuuf")}}]),n}()}]); 

 !function(){"use strict";var classCallCheck=function(instance,Constructor){if(!(instance instanceof Constructor))throw new TypeError("Cannot call a class as a function")},Wheel=function(){function Wheel(){classCallCheck(this,Wheel)}return Wheel.prototype.pump=function(){console.log("puuuuf")},Wheel}();(new function Car(){classCallCheck(this,Car),this.wheel=new Wheel}).wheel.pump()}(); 

I think no further explanation is necessary. But there are problems. Major 2:

• Requires java
• Inconvenient to tune It is poorly integrated into the webpack, which, as you understand, is loved not only for tree-shaking.
  In general, Google closure compiler (GCC) requires an analysis of all your code. This imposes its own limitations, but also gives buns in the form of optimizations that are inaccessible from the default Webpack.

GCC starts like this:

 java -jar node_modules/google-closure-compiler/compiler.jar --compilation_level ADVANCED --language_in=ES6 --js ./src/index.js ./src/module.js > out.dev.js 

The first problem is completely solved, especially since there is a brake, but still javascript version.
My next article in this series will be about the second problem, in it I will try to integrate the google closure compiler into the assembly.

PS:
Most recently, a colleague suggested that for GCC a plug-in for webpack came out, I launched , checked, the code was clearly less, but tree-shaking did not work. Apparently the article about setting up GCC is still needed.

 var __wpcc;void 0===__wpcc&&(__wpcc={}),function(c){"use strict";var n;void 0===n&&(n=function(){}),np="",n.src=function(c){return n.p+""+c+".out.dev.js"}}.call(this,__wpcc);var __wpcc;void 0===__wpcc&&(__wpcc={}),function(c){"use strict";var n=function(){},o=function(){},t={};n.prototype.pump=function(){window.console.log("puuuuf")},o.prototype.turn=function(){window.console.log("turn")},t.Wheel=n,t.Rudder=o,(new function(){this.wheel=new t.Wheel}).wheel.pump()}.call(this,__wpcc); 

Instead of output

Perhaps you have a question: how exactly all this Will tree-shaking affect my build?
To be honest, right now I can not answer this question with full responsibility. There is an opinion that it will not be worse, it will be better. How much? The question is complicated. If you try, share in the comments. I, in turn, promise to keep you informed, and as soon as there are worthy thoughts on this subject, I’ll share them with pleasure.