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
This will mean that the tropohouse's unipackages are read-only
again (they used to be, due to extractTarGz's read-only nature, before
cross-platform merging was implemented)
symlink as a special case for runner only
future commits on this branch will add a
package.json/npm-shrinkwrap.json that can be used by "meteor bundle"
users
A package may depend on some files in its dependencies being executable,
so builder ought to respect the modes of source files when copying into
a bundle.
The file watcher (watch.js) calculates the sha1 hash of source files
to see if they've changed. For static assets in `public`, the bundler
then calculates the same hash again for the client manifest.
This commit adds a small optimization to return the hash calculated by
the file watcher, so that it can be reused by the bundler.
There are more optimizations that probably could be done to avoid
other unnecessary sha1 hash recalculations, but they'd likely need
larger architectural changes.
From tool-refactoring to sso.
Makes the tool-refactoring/sso diff a little smaller (including removing
some files from it entirely) and easier to review. Only took about five
minutes to prepare, I swear this isn't a total waste of time :)
We were partway here already: the client served assets from the manifest instead
of from a static directory (since 5b8e1c1), and we already generated the list of
assets in the slice JSON file. But on the server, we ignored that list and
re-walked the asset directory at bundle time.
Now, the idea of asset directory is solely a part of initFromAppDir.
This also fixes a bug where assets that weren't associated with on-disk files
wouldn't work properly if Asset.get* is called in a package loaded with
unipackage.load. Not really sure how dev-bundle-fetcher even worked...
Also fixes a bug in builder where generated filenames didn't actually avoid
duplicate files.
This does not bump BUILT_BY because the previous commit did, and this commit
will not be pushed without the previous commit.
With the precedence bug fixed, more directories are placed into
usedAsFile... enough to break nodeModulesMode=symlink. Fortunately bundler-test
did catch this.
The somewhat hacky fix is to look carefully for reserved empty directories and
replace them with symlinks. This may not be 100% correct; see the XXX comment.
