This reverts commit 4e4e204ab0.
This commit caused a strange regression in reliability of the Windows
dynamic-import self-test, which may be an indication of a deeper problem,
so it seems safest to revert this change for now.
In case empty .meteor-portable-2.json files are written, I've added an
additional check that the cached JSON value is a boolean.
As illustrated by #9554, if a custom .babelrc plugin such as
@babel/plugin-proposal-optional-chaining imports a missing dependency such
as @babel/core, that failure causes inputFile.require to throw an
exception that looks a lot like @babel/plugin-proposal-optional-chaining
itself is missing, which can be confusing.
This change does not fix the underlying problem (the @babel/core package
still needs to be installed), but it does expose the exception so that the
developer can do something about it, rather than merely leaving the ?.
syntax uncompiled.
Here's the offending line of code:
47ce7e71c9/packages/babel-plugin-proposal-optional-chaining/src/index.js (L2)
Unfortunately, depending directly on @babel/core seems to be the policy
for Babel plugins, per this PR: https://github.com/babel/babel/pull/6778
Previously these files were written asynchronously in an attempt to
improve performance, since the success of the write is not critical.
While I stand by my claim that it's acceptable for these writes to fail, I
noticed recently that the async write was failing very often (resulting in
an empty .meteor-portable-2.json file). Switching to sync semantics
eliminated that problem with no noticeable loss of performance. In fact,
overall performance is likely better because of the future work saved by a
successful write.
In an attempt to fix#9552, recursively scan child directories of
directories that start with '@' characters, rather than treating the
parent directory as a potential npm package.
Also, ignore directories that start with a '.' character, such as the
common node_modules/.bin directory.
Since these packages aren't published to the npm registry, they can be made private to avoid unnecessary warnings about missing description, repository, and license fields when installing server dependencies and generating dev bundles.
Previously, the async fallback was only used in case of ENOTEMPTY errors,
but Windows appears to throw temporary EPERM errors as well. If the errors
are actually robust/non-temporary, the async version will fail, too.
Should help with #9540.
Fixes#9383.
A subclass contructor should generally invoke a superclass constructor with
appropriate arguments. Exactly how this happens has changed with the
advent of native ECMAScript class syntax.
With native ECMAScript class syntax, invoking the superclass constructor
requires calling super(...args), rather than calling the constructor as a
function against the instance object (this), which is now forbidden
because native ECMAScript class constructors are not callable.
The goal of making native constructors not callable was to prevent the
accidental omission of the `new` keyword. However, the old style of
calling the parent constructor function against the child instance almost
always used .call or .apply, so the ommission of `new` was not a mistake.
With that insight in mind, I have added two new static methods to
Mongo.Collection for the sake of backwards compatibility with existing
code that attempts to subclass Mongo.Collection.
These methods, .call and .apply, invoke a new (non-static) this.init
method against the provided instance. The this.init method is also invoked
by the actual constructor, so calling Mongo.Collection.apply(this, args)
works essentially the same way it used to, before native class syntax and
super(...). This trick effectively reenables calling Mongo.Collection.call
and .apply, facilitating subclassing by non-native function-based classes.
Note: both .call and .apply will throw if the provided child instance is
not instanceof Mongo.Collection.
Inheriting static properties can be difficult without native class syntax,
too. To avoid breaking some widely-used, partially correct idioms (such as
using a for-in loop to copy static properties from the superclass to the
subclass), I decided to make all the static properties of Mongo.Collection
(except for "call" and "apply") enumerable. Here's some code that
illustrates what would break if static methods remained non-enumerable:
d791a697a5/collection-hooks.js (L280-L284)
Though these tricks are clever in a way that doesn't feel entirely
bulletproof, they do fix most code that would have been broken by
converting Mongo.Collection to a native ECMAScript class (in Meteor
1.6.1), thus allowing us to avoid converting Mongo.Collection back to a
non-native function-based class.
The last version of stylus published did not contain a version of the
caching-compiler package that these tests now depend on, so I've removed
the extra architecture matching for the stylus package (not for less).
To fix#9528, we included more information (the target architecture) in
cache keys for files compiled by CachedCoffeeScriptCompiler. Although this
change was right and necessary, it altered the caching behavior tested by
this self-test. Specifically, .coffee files must now be recompiled for the
os.* architecture, whereas previously code compiled for web.browser could
be accidentally reused on the server.
Although it was tempting to avoid including the SockJS library in the
bundle for modern browsers, Meteor 1.6.2 will have a much better way of
managing this kind of differential bundling for modern/legacy browsers
(see PR #9439), and removing SockJS seems to lead to a worse experience
when native WebSockets end up failing, as @jamesmillerburgess discovered:
https://github.com/meteor/meteor/pull/9274#issuecomment-356214405
We've seen some recent intermittent test failures because previous
CallbackLogger results were accidentally carried over when there should be
no results. This change allows running a callback function after resetting
logger._log.length to 0, to ensure the callback adds nothing to the log.
Self-tests that are marked as "slow" are not run automatically for pull
requests, but they should be run before a release.
It was a mistake to publish the first Meteor 1.6.1 release candidate
without running these "slow" tests, as the cordova-builds test would have
caught the problem reported by @macrozone in #9521.
I've decided to remove the "slow" marker from this test, since it's
important for checking Cordova sanity, and clearly could fail.
In order to install Gradle, which is required for Cordova tests to run
in the Meteor self-test suite, this image slightly builds upon the
CircleCI image we'd been using previously.
