Partially reverts commit 8364f81344.
This commit was causing self-test failures like the following:
While selecting package versions:
error: unknown package in top-level dependencies: dynamic-import
I suspect these tests won't work until the dynamic-import package is
published with a non-prerelease version.
It's tempting to make the ecmascript package api.imply("dynamic-import"),
but the dynamic-import package depends on the ddp package, which depends
heavily on the ecmascript package, and I'm not sure how best to break that
dependency cycle.
* Update Contributing.md.
Various changes and cleanups to the Contributing information but primarily, remove the team mentions part of "Need help with your pull request?" (which don't work unless you're a member of the GitHub org). In general, contributors can get ahold of the correct person(s).
/cc @hwillson
* Update Contributing.md
* Added a small note explaining how to get dev_bundle changes published.
* Fixed grammar errors with 's; Updated @meteor/platform mention.
* Removed @meteor/platform suggestion since it can only be used by team members.
* Remove nested properties from upsert selector document
Fixes https://github.com/meteor/meteor/issues/8631
* Fix upserts that include _id in the selector
* Incorporate PR review requests.
This should act as a reminder for those who may be using `smtp://` when
they should be using `smtps://`. Previously, the scheme was implied by
the port number, however this is not the ideal behavior in the same way
that it is unsafe to assume that port 443 is always `https://`.
Now anyone can define meteorInstall.fetch however they see fit, and the
install.js implementation will handle everything else.
This separation of concerns leads to significantly less code, too.
As proposed here: https://github.com/rollup/rollup/wiki/pkg.module
By supporting ECMAScript module entry points for npm packages in Meteor
1.5, we will be well-positioned to do more effective import/export-based
tree shaking in future versions of Meteor.
We can't do the same thing on the server because we can't change how
native Node resolves package entry points based on the "main" field of the
package.json module.
On the other hand, all npm packages have to work in Node using the "main"
field, and client bundles stand to benefit the most from tree shaking, so
this client/server difference should not be problematic.
Note that the "jsnext:main" property is also supported as a legacy synonym
for "module".
