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
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.
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.
* Change error suppressing property in livedata_connection.js
Fixes#6912
Switched the property from `expected` to `_expectedByTest`
* Update History.md and bump package patch versions
PR #9343 changed the return type of Boilerplate#toHTML from String to
Stream, which is likely to break existing code that expects a string.
In order to make the change in return type more obvious, I have renamed
the method to toHTMLStream, and I have attempted to update all call sites
appropriately. However, because this change comes in the release candidate
phase of Meteor 1.6.1 testing, it seemed important to preserve the
string-returning behavior of toHTML, with a deprecation notice.
Unless third-party code is using the Boilerplate class directly, I don't
think the toHTML method will ever be called, and we can remove it in
Meteor 1.6.2.
Thanks to @macrozone for tracking this problem down.
Fixes#9521.
https://github.com/meteor/meteor/pull/9274#issuecomment-355241004
The `Error in connection establishment: net::ERR_CONNECTION_REFUSED`
message will still repeat every few seconds, but devtools should coalesce
it into a single line with an incrementing counter, as before.
This is a back-port of a similar change on the web.browser.legacy branch:
b8601d3ce7
To save size in modern browsers, JavaScript bundles built for the
web.browser architecture no longer statically include the SockJS library.
That's safe as long as native WebSockets actually work, but what if
there's a problem with the network that necessitates falling back to
long-polling or some other SockJS strategy?
In those cases, we can load SockJS using a dynamic import(), which is a
little slower than including it in the bundle, but that's OK because the
module will be permanently cached in IndexedDB in production, and falling
back to SockJS should be rare in modern browsers anyway.
Note that this trick would not be possible if the implementation of
dynamic import() still required a socket connection! (#9384)
Client side `Accounts.onLogin` callbacks are triggered after a
successful login, but they're also triggered after a successful
DDP reconnect (if already logged in). As discussed in #5127,
some people think this is the correct behaviour, while others
feel that `onLogin` callbacks should really only fire after a
user has actually logged in (e.g. after using something like
`Meteor.loginWithPassword`). Since people are split on the
proper approach here, an alternative solution would be to
provide client side `Accounts.onLogin` callbacks with a way
to tell if they're being called after a login or after a
reconnect, then let them decide what to do.
Server side `Accounts.onLogin` callbacks receive an object that
contains various login details. One of those items is a login
`type`, that can hold values like `password`, `resume`, etc.
When a user completes a true password based login, the returned
login `type` is `password`. When the user is already logged in
but undergoes a DDP disconnect + reconnect, the returned login
`type` is `resume`. This means server side `Accounts.onLogin`
callbacks have a way to tell which type of login is happening,
allowing them to respond accordingly.
This PR adjusts client side `Accounts.onLogin` callbacks such
that they also receive a single login details object, that
contains login type information. Unlike the server side login
details object, the client side login details object only
contains the login type (to help reduce network transfer
overhead, make sure we're not exposing server details on the
client we shouldn't be, etc.).
This approach should give developers a better way to respond to
different client side login types, and act accordingly.
Fixes#5127.
