The extra legibility is not as useful for code that is always part of
core as it is for user's packages, and it actually has a notable (25%)
effect on isopacket load time.
Fixes#3218.
For freshly created apps, this commit reduces the time required to start
the development server from 4.6s to 2.5s on my machine.
Not calling findMongoAndKillItDead unless Mongo fails to start shaves off
a few hundred milliseconds, too.
Fixes#3010.
This means that the first command won't need to do a big build (and
print lots of package changed notifications). Similar to what 'meteor
create' does.
Also add --prepare-app command.
It wasn't really being used for anything anymore except complaining
about api.versionsFrom being used during isopacket builds, which is now
implemented in a simpler way.
This command was changed in 0.9.0 to do something of questionable use,
and was temporarily unimplemented as part of work on #3006. It now does
something relatively simple to describe: It prepares your current app
for build, and in addition, it downloads EVERY package in your current
release and builds EVERY available local package (including those which
you are not using in your app).
There's only one call site which always passed {requireVersion: true,
defaultVersion: "0.0.0"}, so just inline those values.
Also, move some validation of the version string into the place where it
is set instead of some other random place.
This reimplements functionality that had been removed as part of the
`isopack-cache` branch refactoring.
Information about package changes is encapsulated inside a
PackageMapDelta object on the ProjectContext. It is the responsibility
of the command that prepares the ProjectContext to choose to call
projectContext.packageMapDelta.displayOnConsole at the appropriate time
if it wishes to display changes.
Part of #3006.
This commit fixes a 0.9.3 regression where the calculation of the
topLevelPrereleases object was not updated with the introduction of
disjunction constraints (||) and would always be empty.
topLevelPrereleases and useRCsOK are merged into a single
anticipatedPrereleases option which is now passed in to the
constraint-solver package rather than constructed inside it. (This
object will also be used in ProjectContext as part of PackageDelta
calculation.)
The usedRCs return flag is now called
neededToUseUnanticipatedPrereleases.
One of the actual dependencies (as opposed to devDependencies) of
pathwatcher (fs-plus) depends on rimraf, but it doesn't get installed in
pathwatcher/node_modules/fs-plus/node-modules/ because it's already
installed in pathwatcher/node_modules/, so we should avoid deleting it.
MAJOR INTENTIONAL CHANGES
- Structured project initialization through a new ProjectContext
object. Everything about initializing project metadata, resolving constraints,
building local packages, etc now happens EXPLICITLY when it is requested
instead of implicitly at low levels of the code. This makes it much easier
for us to do proper error handling and to guess which parts of the code are
fast operations and which might cause build steps, downloading, etc to
occur.
Most commands just create a ProjectContext object and call
prepareProjectForBuild (in a buildmessage capture) on it; this function reads
project metadata, runs package.js files to initialize the local catalog,
resolves constraints, downloads missing versioned packages, builds local
packages, and saves any changed metadata. Commands that need finer control
can advance the state machine to an earlier stage of the process; eg, 'meteor
add' just reads metadata and initializes the catalog, then adds some
constraints, and then continues the rest of the project preparation.
Most of the metadata files have an explicit class in ProjectContext to
represent their state. The files are read properly using WatchSets. The file
classes can be used independently of ProjectContext too.
- The constraint solver is never run on individual packages!!! It is only run
in the context of the entire project. Formerly, it was run in the project
context as well as for each local package being built (including the app
pseudo-package).
- Fewer singletons. There is no `project` singleton any more; ProjectContexts
are managed dynamically. There is no `catalog.complete` any more; a
ProjectContext has a `projectCatalog` (which corresponds to the old layered
catalog.complete) as well as direct access to the `localCatalog`. We still do
have `catalog.official`.
- Built packages are cached per app instead of in the source tree. The main
upside here is that if you are sharing a package source tree between multiple
apps, you don't have to deal with the concurrency issues and constant rebuilds
if dependencies/meteor releases are different between apps. This also means
that you don't lose package caching if you don't have write access to the
source tree. The logic around the per-app cache is much simpler and more
likely to be correct.
There are some downsides here! For example, `meteor create` is slower than it
used to be because it needs to compile all the packages used by your app
rather than relying on them having a cache in a build tree. And commands that
build packages but don't maintain an app have to rebuild every time; most
notably, publish and test-packages. (For test-packages I hope to add some hack
to make this faster; for the time being you can use the `--test-app-path` flag
that was added for cordova to point to some random directory which can get
reused across invocations.)
- The only packages that ever get built or loaded into memory are those which
the constraint solver tells us are part of your package. A corollary here is
that if tool code has bugs where it tries to use a package that's not part of
the package map returned from the constraint solver, it will crash instead of
silently building the package. This is a good thing, and has highlighted some
inconsistencies in our model.
- Some tweaks have been made to the constraint solver's input and output. We
include plugin dependencies as constraints now; this means that if you are
building a package which contains plugins from source, the package choices
made for the packages going into the plugin have to be consistent with the
choices made for the broader project. Also, we now enforce dependencies at
the simpler package level rather than at the unibuild level; this means that
your .meteor/versions file may contain versions for packages that don't
contribute any unibuilds to your app but which are required in order to build
other packages that do.
- The versions.json file from package source and bundled package source trees is
gone. In its place is a `.versions` file which always exists in bundled source
tarballs and which exists in package source trees only when the package is not
inside an app. This file looks like .meteor/versions, not its own JSON schema.
- We no longer support the "programs" directory inside a project source tree,
which was designed for a previous Galaxy prototype.
TEMPORARY ISSUES WHICH WILL BE FIXED ON DEVEL
The following regressions will be fixed after merge; they didn't seem important
enough to block merging. They are all marked with "XXX #3006".
- Commands no longer print messages about what packages have changed. I just
need to think of a good API that doesn't involve literally printing messages
at a low level in the code, and go back and implement it. See
#ShowPackageChanges in the code.
- The warning that you're using RC versions that you didn't ask for is not being
printed.
- --get-ready is not implemented (it just fails with a message). It did
something weird in recent versions and can now do something much simpler,
but I have to actually implement it.
- I have not tested make-bootstrap-tarballs
- Most self-tests (even slow ones!) pass. The following (slow) ones don't:
- package-tests: sync local catalog
- package-tests: update server package data unit test
- package-tests: talk to package server with expired or no accounts token
- package-tests: packages with organizations
- publish: publish-and-search
- publish: publish-one-arch
- publish: list-with-a-new-version
- publish: do-not-update-to-rcs
- publish: package-depends-on-either-version
- report-stats: report-stats
