If you call api.mainModule(path, where, { lazy: true }), that main
module will not be evaluated until other code imports it at runtime, and
won't even be bundled if no other code imports it.
Closes#6132.
Similar to the treatment given to PackageAPI in my commit
af50b4cc5b.
This clear separation of concerns will be helpful for optimizing
PackageSource#initFromPackageDir.
The main module serves the crucial purpose of combining all the exports of
other modules in the package, which eliminates the need for api.export in
principle, though the module.exports of the main module (also defined as
Package[packageName]) will still be populated with any api.export-ed
properties.
We only got away with this because we later use _.values to iterate over
the elements of the array, which just happens to do the right thing when
the array is overloaded with object properties. The order of iteration was
even the same because object keys are enumerated in order of assignment,
but when you're working with an ordered list of files it's better to use
an array the normal way (for its elements rather than its properties).
1. Add `addAssets` API to `package.js`
2. Rename `getSourcesFunc` to `getFiles` in internal code
3. Changed `PackageAPI#sources` to `PackageAPI#files` with a new structure that
has separate objects for assets and sources
4. Added some tests for different error conditions
5. The same file can now be a source and an asset
The exact borderline between "Isobuild" and "the tool" is a little hazy,
but the idea is that "Isobuild" is the part that you could imagine being
embedded in a non-command-line build tool. It's not about commands or
UI, but just about building packages and apps.
A next step could be moving things that are strictly "the command-line
tool" into their own subdir, and leaving the top directory mostly just
for shared utilities like buildmessage. (Which could even go in a utils
subdir?)
