These deprecation warnings were introduced in mongodb@3.1.2:
https://github.com/mongodb/node-mongodb-native/commit/a5d0f1d7e1
Fortunately, the deprecated Collection methods still work, and the
deprecation relies on Node's require("util").deprecate API, which can be
silenced permanently for a given function by temporarily setting
`process.noDeprecation = true` while defining the function:
https://github.com/nodejs/node/blob/2ae98ce7cb/lib/internal/util.js#L23-L29
Fixing #10174 by updating mongodb seems more important than reverting the
update to silence these harmless deprecation warnings (which, it bears
repeating, were introduced in a patch update).
Thanks to @klaussner for raising this concern!
Note: since Babel 7 is out of beta now, not all Babel-related packages
have been bumped to 7.1.0. In particular, the @babel/runtime package is
still at version 7.0.0. This is great news, because it means we're back to
genuine semantic versioning for all Babel packages!
My attempt at fixing #10195.
@klaussner Feel free to submit your PR if it's ready, or just review this
one if you prefer. It's important to get this right, so it's not a
terrible idea for both of us to attempt it independently.
Meteor 1.6.x through 1.7.0.x use the `babel-runtime@1.2.x` packages, and
this change is only intended to affect those versions.
This will no longer be necessary in Meteor 1.7.1, since we account for
the changes to `@babel/runtime` through changes to the `meteor/babel`
package, but this ensures that anyone who updates to `@babel/runtime@7` (the
final, latest release), or anything newer, isn't surprised by their broken
application.
After publishing coffeescript@2.3.1_1, I noticed that the version of
babel-runtime (1.2.5) that is bundled into the compile-coffeescript plugin
was complaining about the presence of @babel/runtime@7.0.0-rc.1 in the
node_modules directory of Meteor 1.7.1-rc.3 apps, thanks to code added
recently to work around breaking changes in @babel/runtime@7.0.0-beta.56:
4d5fff99eb
The easiest way to fix this problem in the short term is to give the
compile-coffeescript plugin its own reliable copy of the @babel/runtime
npm package, rather than delegating to the version installed in the app.
The ideal long-term way to fix this problem would be to stop precompiling
Meteor compiler plugins before publishing them, and instead treat them
like any other Meteor package, which are compiled after installation.
Another issue that could have been prevented if compiler plugins were
compiled upon installation, like other packages: #10148
cc @hwillson @abernix @GeoffreyBooth
