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.
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.
