Thanks to changes in the `build-node-for-dev-bundle.sh` script done in
0583e5883c, we now build a tarball which
is identical to the structure provided by Node.js themselves.
While generally we are using the main Node releases, this will allow
our users to (if need be), use a tarball directly in place of their own
in production without additional changes. Similarly, the only change
we need to make now when building the dev bundle is to use a different
URL.
The changes added in
d854a4b9ba
fixed a long standing issue where the Accounts system was
overwriting other DDP `connection.onReconnect` callbacks,
that were potentially set by developers (and vice-versa -
developers could overwrite the `onReconnect` callback registered
by the Accounts system, which impacted logging back in after
reconnecting). Unfortunately these changes are also registering a
new duplicate `onReconnect` callback to be called, after every
login. These duplicate callbacks pile up and are all called when
reconnecting, which eventually breaks user logins.
The changes in this commit make sure that any previously set
Accounts login `onReconnect` callback is first removed, before
adding a new callback. This ensures the Accounts system is only
ever setting one `onReconnect` callback after logging in.
Fixes#9140.
When the ecmascript package version was last bumped in
18e4c172f2, it appears that
babel-compiler@6.20.0 had not yet been published, so ecmascript was
published with a copy of that compiler plugin that did not support the
"env" property of .babelrc files (#8963).
Bumping again and republishing in hopes of fixing that problem.
The `subMatcher` function `let` statment was missing
(dropped during the latest minimongo refactoring - see
fe576f60ce).
This turned `subMatcher` into a global function, which caused
several minimongo issues.
Fixes#9111.
This used to "work" (somewhat accidentally) before we got stricter about
which `node_modules` directories `Npm.require` can search:
971d2b1272
This commit should fix the problem with `juliancwirko:postcss` reported
here: https://github.com/meteor/meteor/issues/9094#issuecomment-331964596
Note that this only works for `Npm.require` when called during the build
process, not at application runtime. Use ordinary `require` for that.
Although this flag allows the build process to be more aggressive about
collecting garbage, it has also been a source of several problems in
Meteor 1.5.2 and Node 4.8.4, from increased segmentation faults during
garbage collection to extreme slowness in rebuilding local packages.
We still use this flag in the Meteor 1.6 betas, where it appears to cause
no problems. For Meteor 1.5.x, however, I think we need to prioritize
development reliability over memory efficiency, for now.
Fixes#8648.
Fixes#9094.
This reverts commit 6b80cdaea4.
I'll re-introduce this commit to the release-1.6 branch so it doesn't
interfere with 1.5.x releases on the active `devel` branch. The PR
should have likely targeted the 1.6 branch anyhow.
Calling unwatchFile may result in stopping the watcher before watchFile is
called, which then restarts it. This temporary stoppage appears to cause
change events to be missed sometimes. In particular, preventing this
stop/start with the acrobatics in this commit seems to fix recent
compiler-plugins.js test failures.
Since 8c70716954, optimistic file watching
uses far fewer file descriptors, so the original motivation of setting
this environment variable no longer holds.
