We were overwriting the server directory when a client-side file changed,
which made all process calls fail, such as process.cwd() and fs.*. We
abstracted out some of the builder code so that only the client targets
are "rebuilt" when a client side file changes.
- in add, we actually do want to know the added version
- in remove, there's a distinction between truly dropping the package
and just dropping the top level constraint
Hopefully this isn't ignoring real error cases. The whole
previousSolution data-rewriting hack probably needs to be fixed
anyway. But this seems to work?
This allows `catalog.official.refresh` to be called during another
refresh that has yielded.
`catalog.official.refresh` still cannot be called re-entrantly, so
`recordOrRefresh` checks if a refresh is in progress before starting a
new one.
Of course, if we were to simply set forceRefresh to true from where
catalog.official was calling catalog.complete.refresh, then we would
have looped inifinitely: initializing the catalog with a `versionsFrom`
field pointing to an unknown release would call
`catalog.official.refresh`, which would call `catalog.complete.refresh({
forceRefresh: true })`, which would call `catalog.official.refresh`
because the unknown release is still not found, and so on.
`catalog.official.refresh` doesn't do any of its actual work when called
reentrantly or when called during a `catalog.official.refresh` yield, so
it makes sense for `catalog.complete.refresh` to be part of that work;
in other words, `catalog.complete.refresh` shouldn't be called if
`catalog.official.refresh` is called reentrantly or during a yield, just
as we don't hit the server again under such conditions. And this also
prevents the infinite loop.
For reasons I don't fully understand, putting the
`catalog.complete.refresh` call before the futures are returned didn't
quite work. Turns out the refreshFutures aren't actually used anyway
(Future wasn't imported from this file; I have a sneaking suspicion the
refreshFutures thing hasn't actually been tested) so this is basically
dead code, and I replaced it with just making `catalog.official.refresh`
return immediately when called re-entrantly or during a yield.
Now we're successfully checking with the server before declaring that a
package/release doesn't exist, and not infinite looping if the
package/release really doesn't exist even on the server.
Specifically, in cases (like "load the most recent release we know
about") where we don't always want to incur a sync RPC.
Apparently, there is literally no way to get data from catalog.official
without a sync RPC occuring.
This speeds up 'meteor --version' on built releases by a factor of 10
Send them only on 'run' (which is likely to be running for a long time,
giving us plenty of time to send stats) and 'deploy' (which has to go
over the network anyway), though we don't wait for stats to be sent
before exiting from any commands.
Update stats self-test to run apps instead of bundling them. Add an
environment variable to print some output about when package stats have
been sent for the test to know when it's okay to stop the 'meteor run'
process.
