Remove deprecated code from before Meteor 1.0 that was documented via XXX COMPAT in comments. Move deprecated packages into the deprecated folder (deps, livedata, srp).
https://github.com/meteor/meteor-feature-requests/issues/135
This change allows applications to specify specific entry points for each
architecture, without relying on `imports` directories to determine the
eagerness/laziness of modules. In other words, it will finally be possible
to build a Meteor app without a special `imports` directory.
Specifically, if `packageJson.meteor.mainModule[architecture]` is defined,
all modules for that architecture will be lazy except for the specified
module, which will be loaded eagerly.
Possible values for `architecture` include "client", "server", "web",
"web.browser", "web.cordova", "os", and so on, just like the second
argument to `api.mainModule(file, where)` in Meteor packages.
In order to match existing behavior, a Meteor application might include
the following in its `package.json` file:
"meteor": {
"mainModule": {
"client": "client/main.js",
"server": "server/main.js"
}
}
These architectures are handled independently, so omitting the "client" or
"server" property would cause that architecture to revert to standard
Meteor loading semantics. In other words, Meteor developers must opt into
this functionality, which is crucial for backwards compatibility.
Note that this functionality applies only to application modules, since
modules in Meteor packages are already lazy by default, and Meteor
packages can already specify entry points by calling `api.mainModule` in
their `package.js` files.
Also note that the loading behavior of non-JavaScript resources is *not*
affected by `packageJson.meteor.mainModule`. Only resources added by
compiler plugins via `addJavaScript` are subject to the new configuration
option. If a compiler plugin calls `addStylesheet` or `addHtml`, those
resources will still be included unconditionally in the HTML document
rendered by the web server. While you could try to import these resources
from JavaScript, you would only be importing any JavaScript resources the
compiler plugin registered using `addJavaScript`, and not the actual HTML
or CSS resources. I welcome feedback on this decision, but if there's no
meaningful way to import a resource, making it lazy just means it won't be
loaded at all.
An ulterior motive for this feature is to enable Meteor apps to have
directory layouts that developers who are not familiar with Meteor can
immediately understand. The special meaning of the `imports` directory and
the surprising eagerness of modules outside of `imports` have always
required some explanation, so this change should reduce that surprise.
Because Meteor strives to be a zero-configuration tool, this is currently
the only supported option in the "meteor" section of `package.json`,
though the available options may be expanded in the future if that's the
best/only way to solve important problems. This would involve adding
additional methods to the `MeteorConfig` class in `project-context.js`,
and then using those methods elsewhere in the `meteor/tools` codebase.
This traces back to my commit a9fde48ca8.
The problem went unnoticed because the only symptom was that duplicate
files were not properly reported.
The "compiler plugins - addAsset" self-test checks for the "Duplicate
source file" error, and was passing until recently, but began failing
after I fixed a bug in the forAllMatchingArchs function that allowed
duplicate callbacks for the same architecture.
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?)
