This update makes it 3 - 7x faster than standard-minifier-js. It replaces terser with swc, and uses a faster js parser. It also switches to @zodern/source-maps for concatenating the files, which is 16x faster than the library previously used. The package size was also reduced, so it is faster to install.
A couple years ago I added caching to zodern:standard-minifier-js. With caching, it can be much faster, depending on what was changed since the last build.
A number of Meteor packages, especially core packages, don’t have source maps. I’m working on fixing this for Meteor 3, but in the meantime the minifier will now try to create source maps for these packages. It does this in both development and production.
It’s indeed much faster and also consumes less memory.
A zCloud client was having issues building their app with the previous version, it was not working at all for his case, it was breaking even with 10Gbs+ of memory.
The biggest issue blocking bringing the features over is that hiding production sourcemaps causes issues with cordova.
For the performance improvements, we can easily improve the parsing speed in the core minifier, which would save a few seconds for large apps. Switching to swc will be more difficult if we don’t want to drastically increase the size of the js minifier package (it would double from 50mb to 100mb) - I’m planning to at least partially fix this in Meteor 3. zodern:standard-minifier-js reduced the package size, but the way it did so wouldn’t be something we would want to do in a core package.
Awesome stuff @zodern, really cool to see! Will give it a try!
Does this bundler also improve meteor build times? We are running our builds in a Github Action and would love to bring down this current ~5min build time a bit.
Yes, it does make meteor build faster. I wrote a blog post about optimizing CI, which has some other suggestions that could also help: Optimizing CI for Meteor
I am having problems with the handsontable package 12.x and later. In development it works while production generates the error
Uncaught (in promise) RangeError: Maximum call stack size exceeded
at nA (d1066cae49cd7d45c71a7872fcf90d32e1eed066.js?meteor_js_resource=true:5:10452)
at ng.runSetters (d1066cae49cd7d45c71a7872fcf90d32e1eed066.js?meteor_js_resource=true:5:12213)
at ng.runSetters (d1066cae49cd7d45c71a7872fcf90d32e1eed066.js?meteor_js_resource=true:5:12570)
at ng.runSetters (d1066cae49cd7d45c71a7872fcf90d32e1eed066.js?meteor_js_resource=true:5:12570)
at ng.runSetters (d1066cae49cd7d45c71a7872fcf90d32e1eed066.js?meteor_js_resource=true:5:12570)
at ng.runSetters (d1066cae49cd7d45c71a7872fcf90d32e1eed066.js?meteor_js_resource=true:5:12570)
at ng.runSetters (d1066cae49cd7d45c71a7872fcf90d32e1eed066.js?meteor_js_resource=true:5:12570)
at ng.runSetters (d1066cae49cd7d45c71a7872fcf90d32e1eed066.js?meteor_js_resource=true:5:12570)
at ng.runSetters (d1066cae49cd7d45c71a7872fcf90d32e1eed066.js?meteor_js_resource=true:5:12570)
at ng.runSetters (d1066cae49cd7d45c71a7872fcf90d32e1eed066.js?meteor_js_resource=true:5:12570)
when importing the above library.
I noticed that if I use the syntax
import Handsontable from "handsontable"
it generates the error, whereas with the syntax:
import Handsontable from "handsontable/dist/handsontable.full.min".
It works.
For now I’m going back to the standard version, as I don’t want it to generate any more problems. Too bad because the possibility of avoiding the generation of statistics is very convenient.
