Port a simplified version of Meteor.EnvironmentVariable and
Meteor.bindEnvironment to fiber-helpers.js to deal with this.
Identify uses of fiberHelpers.inFiber and switch them to either
fiberHelpers.bindEnvironment (if the callback they are wrapping is
semantically "part of" the context that creates the callback) or
fiberHelpers.inBareFiber (otherwise).
Without this, concurrency was causing the wrong buildmessage message
sets and jobs to be active when builds yielded.
Moving towards a world where all things that might invoke buildmessage.error are
encouraged to be in a buildmessage.capture.
This commit is the answer to the question "how many small changes need to be
made to add buildmessage.assertInCapture to PackageCache.loadPackageAtPath?"
Next steps include:
- Making catalog.resolveConstraints ALWAYS buildmessage.assertInCapture
(not just when ignoreProjectDeps isn't passed)
- Then changing resolveConstraints to complain using buildmessage
- Removing the process.exit(1) in _ensureDepsUpToDate
- Adding a more structured way to ensure that most commands
call _ensureDepsUpToDate at an unsurprising location
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.
In particular, this becomes especially important with packaging
since we ping the server with a DDP connection every time you
run an app. Multiple times actually.
So now there's no ECONN error messages printed
