Meteorites, we have published our 0.3.0 release of our minification plugin: ssrwpo:uglifyjs2. This release adds new options allowing to decrease even more your JS payload. You can find a demo in our repository as well as some documentation in our website: https://ssrwpo.github.io/uglifyjs2/
Happy coding!
This looks awesome! Have you run into any problems with this, or has it just been a straight improvement for your app?
Unfortunately, we have the same problem as the standard-minifier-js as both rely on UglifyJS2.
I was thinking about using babili to avoid them but having Babel triggered twice from the ecmascript and the minifier package seems wrong to me. A single package that would do the transpiling and the minification would be far better.
At least, this package shaves off some of the Meteor.isSever as well as the process.env.NODE_ENV === 'production' that are left in the client. On React sites, it means a lot.
Sure - what I’m asking is, would these be good defaults for the core Meteor minifier package? Everything in the documentation seems like a reasonable thing Meteor should just do out of the box.
Perhaps could be worth filing an issue on meteor/meteor with this link and seeing if we could just make these changes in the next release, or if there is some reason not to.
Apart that it lenghtens the production build a little bit, it’s definitely worth using it. I will add an issue for it. Having it in the core would be far more effective and would benefit our community even more.
I’ve just added the issue with more descriptive about what as been done for this package: https://github.com/meteor/meteor/issues/8319
I tried using this package but have given up after waiting for an hour and a build still had not completed.
I started to wonder if it might be because I have already minified files, maybe @sashko you could answer this for me. I know that you can use “.min.js” to tell Meteor to not minify files, and you can use “.es5.js” to tell Meteor to not run it though babel. Is there a way to have both?
I would assume that we wouldn’t run any compilation on .min.js - like it would be odd to run Babel on minified files. Is that not the case?
You’re right, it looks like thats the case. I could have sworn at one point, many moons ago I had to make the choice between the two, and I chose “es5” instead of “min” for development rebuild speed.
The behavior that you’re depicting may even happen with the standard minifier. Have your tried a meteor reset to purge old builds?
PS: This package doesn’t minify code already being minified: https://github.com/ssrwpo/uglifyjs2/blob/master/plugin.js#L123
I got it working after renaming my minified files to .min.js. It took quite a while to minify, but my project is fairly large. Unfortunately, for me it didn’t cut down on the size of the JS, 1.8 MB gzipped prior and 1.8 MB gzipped after.
Do you have a ton of pre-minified code in your app?
about 30% of the payload is pre-minified. I use a library called SpreadJS, it’s 2.2 MB uncompressed and the entire payload is 7.1 MB uncompressed.