There have been a number of occasions where I have gone to bump the
Meteor docs to the next major version, only to find that the docs
deployment (which occurs in a separate repository; found at
https://github.com/meteor/docs) fails due to code-refactoring which has
taken place in its submodule (`code`, which is this Meteor codebase).
In order to provide early warning when a JSDoc declaration in the Meteor
code is going to (eventually) break the docs deployment which occurs in
a separate repository (https://github.com/meteor/docs), this commit
introduces a simple checkout and doc generation, in the same manner as
the docs would in its own repository, within the CircleCI workflow.
It's been configured in a way where it will not stop the normal Meteor
test-suite from running, however it will show a separate indicator on
GitHub pull-requests as to whether the generation of docs was successful
or not.
* Add a self-test skip option
Meteor's CI infrastructure is configured to exclude certain
`self-test`'s on each run. These excludes are specified in
each CI environment's config file, and included when running
`meteor self-test`. Developers running `meteor self-test`
locally however are not using these excludes by default,
so developer's have to manually look up the current exclude
list from one of the CI configs, then add these excludes to
their own `meteor self-test` call manually.
This commit adds a new `skip` option to Meteor's `self-test`
system, that can be used to skip adding/running a defined
`self-test` (similar in concept to Mocha's `skip` feature).
This provides a way to skip the running of older
`self-test`'s that are no longer needed, but allows them to
be preserved in the `self-test` suite, for future reference.
With this functionality in place, and the older test suites
updated to use it, Meteor's base CI excludes no longer need
to be maintained in their respective config files. The
excludes are all managed at the source (the test definition),
and can be leveraged by anyone/anything calling
`meteor self-test`.
* Log message describing skipped test
* Add manually-ignored count to self-test summary
* Small comment correction
* History.md entry with PR link
Because Promise.asyncApply is only defined on the server, and Meteor 1.6
no longer uses Regenerator to compile async/await and generator functions
on the server, this code no longer serves any meaningful purpose.
On top of that, the babel-runtime.js module is loaded on the client, so
this code was forcing the Regenerator runtime to be included in the client
JS bundle, even if generator functions were not used anywhere else in the
application.
The benefit of removing this @babel/runtime/regenerator dependency won't
be fully apparent until Meteor 1.6.2, since there are probably other
places in client code that depend on it, so it will probably still be
bundled in most applications. However, the new web.browser.legacy system
(#9439) should remove most of those dependencies for modern browsers, as
Meteor 1.6.2 will no longer use Regenerator to compile async/await and
generators for the modern JS bundle.
Update the Meteor Tool to use Mongo 3.6.2 for 64-bit OS'
and Mongo 3.2.18 for 32-bit OS'. A few important mentions:
- As of Mongo 3.6, all Mongo binary downloads include
SSL - there is no longer a non-SSL based download bundle
(so it's a bit bigger, but that shouldn't be an issue).
- Using the `--nojournal` option with WiredTiger based
replica sets is no longer supported (see
https://jira.mongodb.org/browse/SERVER-30760). The
`--nojournal` flag was added in
bcfe072d52
to help reduce the amount of disk space used by Mongo,
but since this option is no longer supported, we'll
have to live with the extra disk space usage.
- Add PR link to History.md
Since Cordova renders boilerplate HTML at build time, and doesn't use the
server-render system through the webapp package, it's important that we
include es5-shim (and sham) statically for Cordova clients.
This logic will go away once we have the web.browser.legacy system to
control differential bundling (#9439), but for now it's necessary for any
Cordova clients that still don't have full ECMAScript 5 support.
Previously, .cache filenames were simply a hash of the absolute path of
the inputFile, which allowed for cache collisions (on disk) between the
same file compiled for different architectures (web.browser, os.*, ...).
Now, the .cache filenames are generated based on whatever information the
compiler plugin deems uniquely identifying about the input file: whatever
is returned from getCacheKey, plus the absolute path of the file.
This code was recently removed in PR #9445, with this commit:
d644705aa8
Rather than removing deprecated code entirely from the codebase, I think
it's sufficient to keep it in packages/deprecated, and print a deprecation
notice whenever the package is used. This way it's clear that developers
should migrate to other similar packages, but we can still release
important patches for those who haven't been able to migrate yet.
cc @hwillson @abernix
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.
