Because it is currently unused and was the only direct use of the 'estraverse'
module, it seems better to minimize the number of dependencies shipped with
Meteor. Admittedly, estraverse is still a dependency of escope, but if we
upgrade escope to a version that has a more specific version requirement for
estraverse that conflicts with our Npm.depends, we'll be shipping two copies for
no reason.
Package.register_extension API.
It didn't even actually work for producing JavaScript files (eg a
coffeescript-like package): see #1410. Package maintainers should have upgraded
to the more powerful 0.6.5 API by now anyway.
Allow dots in package names.
Change the internal representation of "package specs" inside Slice to be a
{package,slice} object instead of a "spec" string.
library.getSlices now can take EITHER a "spec" string or a {package,slice}
object.
Linker-created slice files also separate the slice name with a colon (so eg, you
get URLs like "/packages/livedata:tests.js" when running package tests). (Maybe
this should use a subdirectory instead?)
We call these the pluginProviderPackages because these are the packages that, if
they change, could affect the set of plugins available to this package (and thus
require it to be rebuilt).
In fact, each slice's dependencies already contains pluginDependencies (see
after the linker.prelink call in Slice.build, and recall that a package's
plugins are always active in itself).
This makes saveAsUnipackage -> initFromUnipackage less lossy. Also means that,
eg, plugins don't end up dependent on tests in packages they use.
Use of the json file path as the key in sliceDependencies is kind of hacky, but
I'm viewing buildinfo.json as less of a standardized format as unipackage.json.
That's because this change could introduce or remove a plugin, which affects how
the dependent package is built (eg, could change an extension between being
handled vs static).
Does not affect transitive dependencies.
.meteor/packages in new apps now contains "standard-app-packages", which implies
the standard set of packages like mongo-livedata. There is no special-casing in
initFromAppDir. This line has been added to all the examples, etc.
There's a new concept of "upgraders". "meteor run-upgrader app-packages" will
add standard-app-packages to the app, as well as all of the package in the app's
packages/ directory (an unrelated change since 0.6.4). This will be integrated
soon with "meteor update"; run-upgrader is essentially for testing.
project.add_package no longer adds packages that are already there.
This implies that all exports are package variables, which made underscore,
jquery, and htmljs (which explicitly assigned to fields on the global variable)
break. We now properly encapsulate these packages (except for window.jQuery,
which we let sneak out because bootstrap wants it). This means that packages
that want _ need to use underscore, and packages that want $ need to use jquery.
Also, you can't use _ in minimongo $where any more (matching mongod).
This package was always included in apps, and even if it was possible to remove,
there wasn't a compelling story about when users would remove and replace
it. Plus, not all backwards-compatibility code could even live in it (eg, field
names of objects), so it was incomplete. It also introduced odd load order
constraints.
Instead, we introduce two conventions for backwards-compatibility code:
- Special comments of the form "// XXX COMPAT WITH 0.6.4"
- When feasible, put backwards-compatibility code in a file called
"deprecated.js" in the relevant package.
This is documented at:
https://github.com/meteor/meteor/wiki/Meteor-Style-Guide#deprecated-code-and-backwards-compatibility
Additionally, removed some symbols that existed for backwards compatibility with
Meteor 0.4.0 (changes made 10 months ago): Meteor.is_client, Meteor.is_server,
and (in a method) this.is_simulation.
