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.
