So far I have only removed files from packages that are included by
default in newly `meteor create`d projects. We should probably make a pass
over all the core packages, too.
Summary:
The `Npm.strip` method makes up for packages that have missing or
incomplete .npmignore files by telling the bundler to strip out certain
unnecessary files and/or directories during `meteor build`.
The `discards` parameter should be an object whose keys are NPM
package names and whose values are arrays of strings (or regular
expressions) that match paths in that package's directory that should be
stripped before installation. For example:
Npm.strip({
connect: [/*\.wmv$/],
useragent: ["tests/"]
});
This means (1) "remove any files with the `.wmv` extension from the
'connect' package directory" and (2) "remove the 'tests' directory from
the 'useragent' package directory."
The values can also be objects, in which case the keys of the nested
objects will match nested dependency names. For example,
Npm.strip({
connect: {
multiparty: ["test/"]
}
});
will discard the "test" directory from the "multiparty" package that is
depended upon by the "connect" package.
If you need to discard files from both "connect" and "multiparty", here's
a little trick you can use:
Npm.strip({
connect: {
connect: ["huge.wmv"],
multiparty: ["test/"]
}
});
This makes intuitive sense because requiring the "connect" package from
the "connect" package always returns the package itself.
Test Plan:
Run `meteor rebuild <package>` for the packages whose package.js files I
modified, and verify that the `Npm.strip`ped paths are absent from the
generated bundle.
Reviewers: glasser, nim, emily
Differential Revision: https://phabricator.meteor.com/D865
It might obliterate the package resolver cache, and we just did a package sync anyway.
But we don't want to delay it entirely, because we do want the release-version check.
Part of adding a new command is thinking carefully about whether or not
your command needs to access the catalog. If there are commands without
that careful thought, the tool shouldn't run.
Since 0.9.0 it hasn't had anything to do about anything being
downloaded, just metadata, so the new name is better.
And without auto-retry, there's no need for this to have anything to do
with buildmessage.
Add a bit more support for the very unlikely case that you're running
meteor outside an app and the catalog has no information about any
METEOR@ release.
Since release.load no longer refreshes, we now need to manually
refresh. This is actually a great thing! It lets us look at modern
releases before legacy releases, which is the proper order anyway!
So stop giving tests a way to force-throw it (might break springboard
test; fix this before merging) and stop catching it.
(release.load now just does a single sqlite query!)
