In a previous commit, I changed
doc = _.extend({}, doc);
to avoid using underscore, thus:
doc = { ...doc };
While this may seem harmless, it broke a few Mongo.Collection tests
because _.extend copies *all* properties, both own and inherited, whereas
object ...spread only copies own properties.
However, the correct way to fix this problem is *not* to revert to the old
behavior, since flattening the inherited properties of a document was
never actually what we wanted. The old behavior was subtly broken, too.
Instead, we need to create a new object with the same prototoype as the
provided document, then shallow-copy the own properties. Any properties or
methods inherited from the original prototype will then be available on
the new object, even though they didn't get copied over.
I've intentionally left some trivial formatting changes in this commit to
remind myself which broken tests were fixed by this change.
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 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.
* Fix bug #5665: add DDP.onReconnect(), deprecate conn.onReconnect
Deprecate use of `connection.onReconnect = func`. Instead, a new
`DDP.onReconnect(callback)` method should be used to register callbacks to call
when a connection reconnects. The connection that is reconnecting is passed as
the only argument to `callback`. This is used by the accounts system to relogin
on reconnects without interfering with other code which uses
`connection.onReconnect`.
* Adjust History entry, package versions, code cleanup
* Fix issues with Infinity based login token lifetimes
Several areas of the Accounts system are using the current
login token expiration millisecond limit for different
`Date` based calculations. When `loginExpirationInDays` is set
to `null`, and the Accounts system uses an expiration limit of
`Infinity`, these `Date` based operations fail, since
`Infinity` can't be converted to a `Date`.
These changes replace the use of `Infinity` with a far future
fixed date representation, that's used when
`loginExpirationInDays` is set to `null`.
Fixes#9066.
* Small comment typo
* Remove unnecessary comment
The visualizer seems to have stopped working recently if you reinstall its
npm dependencies without using the existing npm-shrinkwrap.json file,
likely due to changes in indirect dependencies.
The good news is that the package now has far fewer npm dependencies.
However, since the sunburst.js module imports d3-collection explicitly, we
should definitely be depending directly on that package.
cc @abernix
Since all Meteor packages implicitly depend on the meteor package, it
appears packages that register compiler plugins may need to be republished
in order to benefit from f34c5ec926, or else
the `Cannot find module "fibers\\future"` error may occur on Windows.
This misunderstanding of CommonJS module identifiers goes back to 2012:
8f83b2c32e
In Node, CommonJS module identifiers are always delimited by forward
slashes, even on Windows. Using path.join to abstract away the choice of
platform-specific delimiter is therefore pointless.
While this usage of path.join was always pointless, it was also mostly
harmless until #9095, when we stopped falling back to Node's native
`require` function to handle e.g. `Npm.require("fibers\\future")`. That PR
made the misuse problematic on Windows, so this commit fixes that.
A fix to the dynamic-import code to correctly detect modules version.
Without this fix dynamic-import can't detect correctly modules versions
which breaks the dynamic-import cache functionality.
Ever since Meteor 1.3 first introduced a module system based on something
other than `Npm.require`, we've continued throwing missing module
exceptions that refer to `Npm.depends` and/or `Npm.require`, even if the
developer called `require` or used an `import` declaration. This commit
fixes that, so that all missing module exceptions look like 'Cannot find
module "module/name"'.
I also noticed recently that `Npm.require` is capable of returning modules
installed in `node_modules` directories completely outside the app, which
is bad news for development/production reproducibility. Fixed that too.
CC @hwillson who has spoken of deprecating `Npm.require` entirely, and
just using `require` everywhere, instead.
