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.
It's been used on `devel` via b145c7ed4e.
Normally this isn't a problem, but just to avoid issues, this reminder
should help. Can be removed, of course.
Presently, the renaming of directories that are in-use will fail on
Windows. This is already compensated for when `process.platform` is
set to `win32`. However, within BashOnWindows/WSL (Windows Subsystem
for Linux), `process.platform` is equal to `linux`, though the
underlying filesystem is still the same.
Microsoft has stated that it is unlikely that they will remove
`Microsoft` from the `os.release()` value so we check for that.
This simple fix prevents the disappointment of trying to deploy your app
but failing because there's a space on the end of the `DEPLOY_HOSTNAME`
environment variable.
`process.env` always contains string values and assigning a property on
`process.env` implicitly converts the value to a string so it should not
be necessary to check if `typeof` is a `string`.
Fixes Dev Experience.
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.
