A normal dependency of X on Y consists of a "must-use" constraint ("if X is
loaded, Y must be loaded too") and an "ordering" constraint ("if X and Y are
both loaded, Y must be loaded before X").
The previously-existing support for "unordered" dependencies allows you to
create a dependency with "must-use" but not "ordering". This commit adds "weak"
dependencies, which have "ordering" but not "must-use".
As an example, the accounts-base package wants to define some Handlebars helpers
like {{currentUser}} if the handlebars package is being used, but it's fine to
use accounts-base without handlebars. So it should declare a weak dependency on
handlebars.
A package can tell if another package has already been loaded by checking to see
if `Packages.foo` exists. (So as a result, even slices which export no variables
get a `Packages.foo = {}` line.) Weak dependencies do not import symbols into
your namespace; you must access their symbols through
`Packages.foo.someExportedSymbol`. You don't get to use plugins from your weak
dependency.
@export is now an error in test slices.
This is preparation for ensuring that any slice with exports has at least
"Package.foo = {}"; without this commit, both the use and test slice would (with
that change) try to overwrite Package.foo.
Remove the attempt to allow @export in 'use strict' CoffeeScript files:
ECMAScript 'use strict' is fundamentally incompatible with our implementation of
exports, and it was probably a bug that this used to work at all.
You must declare your @exports using single-line ### comments:
### @export x ###
x = 5
This involves some ugly and not 100% correct low-level source hackery, making
some assumptions about the format that CoffeeScript generates.
Apply this to the current tree, which deletes the unused .npm directory from the
ctl package.
Specifically, this deletes the ".npm/package" or ".npm/plugin/foo" directory. We
don't attempt to also clean up the ".npm/plugin" or ".npm" directory, but a "git
clean -df" will do the trick if you really care.
We were looking at "argv._" to find package names, where that was the argv that
was parsed at the top level, where we had no idea that "--production" was a
boolean, so it was pased as "--production=onepackage" and "onepackage" was not
included in argv._.
This is to isolate the NPM dependencies of the package at runtime from the NPM
dependencies of any build-time plugins in the package, which live in
PACKAGE/.npm/plugin/foo.
Before, plugins could see the node modules at PACKAGE/.npm/node_modules, which
was not isolated enough.
(One issue would be that if you happened to switch a package from having runtime
dependencies to having buildtime dependencies, the buildtime dependencies would
not get installed. This is partially an issue because we don't know to uninstall
all dependencies if they are all removed, but even if that is fixed it would
enforce an unnecessary ordering semantics on NPM updates.)
Server assets can be included in a bundle by putting them in the private/
directory of an application, or by registering a build plugin that calls
compileStep.addAsset with a server file. The Assets API (Assets.getText and
Assets.getBinary) allows an application or package to retrieve the contents of
its own server assets.
