We (@abernix and I) have decided to abandon 1.4.3.3 in favor of 1.4.4,
because the changes we wanted to include are slightly more significant
than seems appropriate for a "patch" update.
This gives us all the benefits of @sethmurphy18's great work without the
additional performance hit of using Babili for everything.
With this commit:
% meteor create min-test
% cd min-test
% time meteor build ../min-build
meteor build ../min-build 39.26s user 5.49s system 112% cpu 39.647 total
Without this commit:
meteor build ../min-build 59.28s user 5.23s system 107% cpu 1:00.08 total
Keep in mind this is the best-case scenario for Babili (a very small app).
Larger apps take much longer for Babili to minify.
cc @abernix @glasser @sethmurphy18
Key changes:
1. Custom Babel plugins from .babelrc files (or "babel" sections of
package.json files) are now treated as plugins rather than presets.
2. Nested presets and plugins are now resolved, whereas previously only
the top-level "plugins" and "presets" properties were examined.
The 0.8.0 version line was colliding with release-1.5, causing the modules
package not to be published during the release-1.4.3.x release process,
similar to what was happening with the ecmascript package:
https://github.com/meteor/meteor/issues/8423#issuecomment-287332131
This is a partial revival of my old #5005 pull request. While we never
came up with a good idiom for Promise-based method stubs on the client,
the server-side changes in this commit should fix#8367.
The most important change in this version is that the Reify compiler is
now just another Babel plugin, so it's possible for other Babel presets
and plugins to run before it.
Fixes#8399.
Fixes#8422.
Fixes https://github.com/meteor/babel/issues/13.
While Babili is much better about handling modern ECMAScript constructs
than its UglifyJS predecessor, it may still be possible for an error to
occur during minification.
To account for that unlikely situation, and to preserve the code already
written to assist in that situation, this implements an error re-throw
in a similar fashion to that of 1a380f5532.
The `ecmascript` package, when `use`'d in a compiler, is included in the
build of the package, thus increasing the size. For this simple package
I'm not sure the benefits will actually be worth it.
This points the `blaze` submodule in the Meteor repository to:
https://github.com/meteor/blaze/tree/minifier-babili
This `minifier-babili` branch excludes new HTML5 tests which are failing
on PhantomJS, namely, the HTML5 tests which were added by:
04db0d40ce
While I believe the `VIDEO` tests are the most problematic, there is
nothing about the tests themselves which are lacking. In fact, the
tests do run successfully on the Blaze repository and the changes have
actually been released for a number of months on Blaze itself, however
the submodule in Meteor hasn't been updated until now.
Meteor only uses `blaze` for generating templates in the
`boilerplate-generator` package and doesn't utilize the HTML5 in
question, nor is Meteor responsible for Blaze testing anymore.
Ultimately, our `test-in-console` needs to be updated to use
another option aside from PhantomJS, but I don't believe that should
hold up releasing this Babili minifier which solves a number of issues
in meteor/meteor#8378.
We only need version constraints on core packages in some cases. For
example, when referring to "core" package wrappers (like `npm-mongo`)
which uses an API outside the Meteor build system.
