This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
Fill in all packages without README.md files with a short
README.md mentioning that this is an internal Meteor package.
Break up the top paragraph of a couple of existing README.md
files to be proper long description.
There is more work to do here, involving line wrapping and the like.
By choosing names like Template.registerHelper(…) and Template.instance() (instead of Blaze), we can separate the “Templates” section and the “Blaze” section of the docs.
If an indirect dependency resolves to something other than a semver (or
a GitHub tarball), it will be stored in the 'resolved'. Our shrinkwrap
minifier (which helps to reduce spurious shrinkwrap file changes) needs
to recognize that.
Also, consistently use the "version" field in the minified shrinkwrap
file (which a comment already claimed we could do).
Fixes#1684.
In minimongo, we support various types as _id fields; the most important are
strings and ObjectIds. We have a special encoding that we use when we need to
represent them as strings, but we had a few bugs with using it.
minimongo: The duplicate-ID check in insert needed to check using the encoded
string.
spark OrderedDict: due to linker changes, it was not successfully finding
LocalCollection._idStringify, and so it fell back to the identity
function. Fixed to use weak dependencies. Also, later refactorings have removed
the need for idStringify(null) === null so that special case is removed.
spark branch labels: use idStringify in various places where _id is used as a
branch label.
This is to isolate the NPM dependencies of the package at runtime from the NPM
dependencies of any build-time plugins in the package, which live in
PACKAGE/.npm/plugin/foo.
Before, plugins could see the node modules at PACKAGE/.npm/node_modules, which
was not isolated enough.
(One issue would be that if you happened to switch a package from having runtime
dependencies to having buildtime dependencies, the buildtime dependencies would
not get installed. This is partially an issue because we don't know to uninstall
all dependencies if they are all removed, but even if that is fixed it would
enforce an unnecessary ordering semantics on NPM updates.)
