Regression introduced by the CSS watching code (specifically, f230eba62)
by the sourceIsWatched check. We need to be able to tell the difference
between "source handler didn't do anything because there was an error"
and "source handler didn't do anything because it's web-specific and
this is an os arch".
A simple fix would have been to interpret compileStep.error as
"sourceIsWatched = true", but I didn't think of that until after doing
it the slightly more complicated but more precise way :)
Also, ensure that if the runner rebuilds the client and there's an
error, it properly kills the app process (and the watchers and the
keepalive interval, etc).
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.
also fixes a bunch of other stuff like:
- parseStack markTop works again (so you get the right line numbers in
self-test)
- you can (with appropriate env var) run apps with NO PACKAGES at
all (even ctl)
- more consistently refer to METEOR-CORE@ releases as "Meteor 1.2.3"
We never really used it for anything, and it uses uniload in a
now-unsupported way (uniload in a built release now only can load a
predefined set of prebuilt packages)
Use heartbeatInterval: 0 to disable heartbeats for testing.
No need to add `_internal` to the public connection API because we
can get to the internal session through the server.
