This change allows the Windows "Generate Dev Bundle" script to
automatically get the versions of major bundled versions from the same
script which the Unix script uses, thus preventing different versions of
Node.js, npm, Mongo, etc. from being built into different versions of
Meteor, such as what happened when I published Meteor 1.4.3.2 and failed
to notice the duplication of variables across different scripts.
This behavior now works in a similar way as the 'BUNDLE_VERSION' variable, which
is retrieved from the global `meteor` script except this change uses the
package versions from the `build-dev-bundle-common.sh` script in the
`scripts` directory.
Windows has no concept of the executable bit so it is not applied by the
`fstream` `Reader` when building the tarball which is used in both
`meteor build` and `meteor deploy`. For Windows users, this causes
important scripts (such as `node-pre-gyp`) to not be executable when
the bundles are deployed to Unix platforms (such as Galaxy).
To avoid giving every file executable bits, this applies an executable
bit to the file only if it has read permission (something Windows _is_
aware of) and if it is in a location that Node bin links are typically
placed, the `/node_modules/.bin/` directories.
In a similar fashion as:
* f51c6822ae (Node.js)
* 8ea41588ea (npm)
* 3470516f93 (MongoDB)
I overlooked the multiplicity of these version variables when updating the major package versions during the release of Meteor 1.4.3.2.
While I intend on never making this mistake again, I've also opened meteor/meteor#8505 which consolidates these variables to a single location (in `build-dev-bundle-common.sh`) to hopefully prevent this from happening to anyone else!
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.
