The `wrapFsFunc` function accepts an array of indexes indicating which
arguments are paths. This is particularly important on Windows, due to
the path-conversation which takes place on those strings.
The docs say:
> Indices of arguments that have paths, these arguments will be
> converted to the correct OS slashes
This follows up on the change made from meteor/meteor#8491 which failed
in our release pipeline when publishing for the Windows architecture
for `1.4.4-rc.3`.
Follow-up to 05be2c784c which added new ES6 syntax, but failed to add `ecmascript`.
* Remove ecmascript Object function shorthand notation.
as the `rate-limit` package doesn't currently use `ecmacsript` and using it for just this one instance of ES6 isn't worth it.
* Remove `ecmascript` from `rate-limit` as it is now unused.
* Bump `rate-limit` version in preparation for publishing.
Fixes#8515
In Unix we support adding `TOOL_NODE_FLAGS` when debugging the Meteor
tool itself, however Windows did not currently support it. This should
add that support. As this is a .bat file, I have every reason to
believe that this syntax should work on older versions of Windows as the
syntax of .bat files hasn't changed much.
Helps with meteor/meteor#8513.
* Switch from mailcomposer 0.1.15 -> 4.0.1 (latest, still MIT license).
* Switch from simplesmtp (which only supports mailcomposer 0.1)
to smtp-connection (which supports any mail composer).
* Use smtp-connection@2 (instead of latest) which shares
nodemailer-shared codebase with mailcomposer 4.0.1.
* Add test for long header lines (the original bug being fixed here)
* Add extra test for HTML + text messages
* Document some extra options arguments supported by new mailcomposer
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.
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!
