While Babel 7 seems to work perfectly well, and the process of upgrading
has been useful, the upgrade is going to require Meteor developers to
update the babel-runtime npm package and their .babelrc plugins, a chore
with which Meteor can't help very much.
On top of that, Babel 7 is still in early beta. I don't want to ship
Meteor 1.6 with a critical component that could change in unexpected ways,
and I don't want to wait for Babel 7 to be finalized to ship Meteor 1.6.
Note that the Meteor command-line tool is still implemented using Babel 7,
which has historically been a great way to gain confidence in
Babel-related changes before pushing them out to all Meteor developers.
@GeoffreyBooth This should take some pressure off the CoffeeScript upgrade
for now. Let's aim for Meteor 1.6.1 for Babel 7 and CoffeeScript 2.0.
* 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
New coffeescript* versions are necessary because we've bumped the major
versions of babel-compiler and babel-runtime.
To verify that these new versions work, create a new app with
meteor create --release 1.6-beta.30 new-app
and then add coffeescript to it:
cd new-app
meteor add coffeescript@1.12.7-2-beta.30
If everything works, you should get -beta.30 versions of coffeescript and
coffeescript-compiler, instead of something earlier.
cc @GeoffreyBooth
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.
