- Bumped patch version number 1.0.0 -> 1.0.1
- ES6 syntax and shorthand applied
- Fixed error in instructions - without the `?close` at the end of the redirect URI, the login popup throws an error
- Bumped patch version number 1.4.0 -> 1.4.1
- ES6 syntax and shorthand applied
- Underscore removed as a dependency
- Globals replaced with module exports
- Adjustment of templates to satisfy several HTML validation warnings in newer versions of Chrome
- Added `autocomplete` attributes to inputs
- Wrapped password-only dialogs forms
- Added hidden `username` and `email` inputs to password-only forms to help with accessibility
- Bumped patch version number 1.5.0 -> 1.5.1
- ES6 syntax and shorthand applied
- Underscore removed as a dependency
- check removed as a client dependency
- Bumped patch version number 1.1.15 -> 1.1.16
- ES6 syntax and shorthand applied
- Underscore and random removed as dependencies
- check removed as a client dependency (it still remains as a server dependency)
- Bumped patch version number 1.4.2 -> 1.4.3
- ES6 syntax and shorthand applied
- Underscore removed as a dependency
- Prototype manipulation replaced with class method declarations, resulting in combining a few files
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).
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.
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
