Should fix#9598, thanks to @abernix's diagnosis of the problem:
https://github.com/meteor/meteor/issues/9598#issuecomment-361570289
My later comment in that issue thread is not accurate, since the Babel
wrapNativeSuper helper already pulls in the core-js Reflect.construct
polyfill. Instead, the root of the problem really seems to be Babel's
generation of an unguarded _typeof(Reflect) expression.
This reverts commit dfc0702558.
We've seen some odd test failures (e.g. `passwords - tokens`) and trouble
updating from 1.6.1 to 1.6.2-beta.3 (easily solved with `meteor reset`,
but also worth investigating), so I think we should keep working on the
Mongo 3.6 upgrade in a PR, rather than running all of our tests against
a devel branch that includes Mongo 3.6.
cc @abernix @hwillson
It's nice to match versions, but we couldn't bump the minor version of the
Meteor jquery package without breaking compatibility with the current Meteor
release (1.6.1), since jquery is a core package.
The next Meteor release (either 1.6.1.1 or 1.6.2) will either use the new
1.12.1 version or (ideally) jquery will no longer be a core package, and
thus will not be constrained by the release.
Related: #9605
Note that you can run `meteor npm install jquery` (any version) in your
top-level application directory, and the meteor/jquery package will use
that version instead of 1.12.1.
This reverts commit b06a6af335, where I
attempted to allow `Mongo.Collection` to be subclassed by non-native class
syntax by implementing static `call` and `apply` methods.
As the reproduction in #9595 demonstrates, in order to subclass
`Mongo.Collection` properly given this trick, one would need to override
not only the `constructor` method but also the `init` method that the
`Mongo.Collection` base class calls. Since this implicit expectation is
too much to ask of new subclassing code, let alone existing subclassing
code, I'm afraid the only remaining option is to go back to implementing
`Mongo.Collection` as a traditional constructor function, rather than
using native `class` syntax, so that subclasses can invoke the constructor
using `Function.prototype.{call,apply}` as they've always done.
Changes:
* Use ECMAScript class and arrow function syntax for Tracker.Computation
and Tracker.Dependency.
* Remove the deprecated.js file (no more Deps, Tracker.depend, or
Tracker-related Meteor.* APIs).
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
Thanks to bug reports from @jamesmillerburgess, in Meteor 1.6.1-rc.4 we
reverted a change that unsuccessfully attempted to remove SockJS from the
JS bundle (and instead injected a <script> tag to load SockJS in older
browsers): 365804218f
With this commit, we are once again attempting to exclude SockJS from the
JS bundle for modern browsers, this time taking advantage of the
web.browser.legacy system to control which browsers receive which bundle.
The definition of a "modern" browser is stricter now (essentially, any
browser with native async/await support), so I'm hopeful that browsers
with incomplete WebSocket support will get the legacy bundle, which
includes SockJS.
However, if there are still bugs in modern browsers due to faulty
WebSocket message compression (for example), we should be able to address
those problems directly, rather than reverting this change yet again.
I missed these packages when publishing 1.6.2-beta.0, since I hadn't
bumped their versions in #9439 as I should have, so the release script did
not republish them. Because of this, 1.6.2-beta.0 will not be usable, and
so I will publish 1.6.2-beta.1 ASAP.
The boilerplate-generator version bump is patch rather than minor, since
the relevant changes to that package seemed backwards-compatible.
I've decided to stick with Meteor.isModern for now, since it's false for
both web.browser.legacy and web.cordova bundles, which would make logic
involving a hypothetical Meteor.platform property more complicated than
simply using Meteor.isModern. I'm open to revisiting this later.
https://github.com/meteor/babel-preset-meteor/blob/master/modern.jshttps://github.com/meteor/babel/blob/dfcce32868/options.js#L81
With the minimum versions from babel-preset-meteor/modern-versions.js, the
difference between "modern" and "legacy" browsers boils down to supporting
native async functions.
I'm eager to stop compiling generator functions with Regenerator, and none
of the transforms that compile async functions to native generator
functions seem much better than the Regenerator experience (source maps
are still wonky within the async function, so it's obvious you're not
working with native code).
Native async functions are supported by 73% of desktop and mobile browsers
worldwide (81% in the US), and that percentage is only going to keep
increasing. I see no reason not to embrace this future now.
This led to a regression in coffeescript-test-helper because the truthy
extraFeatures.runtime property allowed require("@babel/runtime/...") to
appear in a compiled CoffeeScript file, though require was not defined.
If @GeoffreyBooth agrees, we could have the coffeescript package
api.imply("modules"), which would make require would work, but I seem to
remember we had some reasons for not doing that previously.
In my research, I found the data used by @babel/preset-env to be more
conservative than necessary, so I have not followed their minimum version
constraints exactly.
For example, every feature of the ECMAScript `Map` API is clearly
supported in Firefox 45+, according to MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#Browser_compatibility
However, @babel/preset-env requires `core-js/modules/es6.map` in any
version of Firefox earlier than 53:
e270fbe7f0/packages/babel-preset-env/data/built-ins.json (L117)
Since I can't find any evidence that @babel/preset-env knows better than
other sources (I think they might just be using a compatibility table that
doesn't go back far enough), I have tentatively trusted MDN in picking
these versions.
If any bugs are ever reported due to this choice of versions and
polyfills, we have two options to fix them:
* Tighten the minimum version constraints so that the affected browsers
are considered legacy instead of modern.
* Include the missing `core-js` polyfills for all modern browsers.
Just as the URLs of static JS resources depend on request.browser, so too
must dynamic modules be loaded from the correct build directory based on
the user agent string of the __meteor__/dynamic-import/fetch HTTP request.
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)
May help prevent the problem that occurred in this Circle CI test run,
since lolex was the package with hash sha1-LycSsbwYDendzF06epbvPAuxYq0=:
https://circleci.com/gh/meteor/meteor/12641
We'll need to set up BrowserStack or headless Chrome tests to exercise
modern JS bundles. It is still very valuable to run tests with
web.browser.legacy in PhantomJS, because most day-to-day development
browsers qualify as "modern," and we don't want "legacy" browsers to
become a blindspot.
Now that both sockjs-shim and es5-shim are using the web.browser.legacy
system instead of injecting <script> tags with the server-render package,
these shared utilities are no longer used anywhere.
