If a test process does not explicitly call process.exit, pathwatcher
watchers may keep it alive indefinitely (either that, or there's a bug
with the persistent:false option to fs.watchFile).
This accidental immortality can be prevented by explicitly closing all
watchers when we no longer have any interest in file change notifications.
We try to kill any mongod processes before starting new ones, but this
change kills it when the development server shuts down, too.
Killing mongo on shutdown is particularly important for tests that run
meteor multiple times in a row, and for whatever reason fail to find and
kill running mongod processes on startup, e.g. because the --port has
changed (#7563).
This comment by @glasser seems to suggest this is a reasonable idea:
https://github.com/meteor/meteor/issues/2182#issuecomment-45685614Fixes#2182 and possibly other related bugs.
Breaking on the first statement in the program used to be the only way to
get the debugger to stop at any breakpoints, but more recent versions of
node-inspector (compatible with Node 4) do a much better job of stopping
at breakpoints after the program starts.
This will make it much easier to fix bugs and make improvements going
forward, since they won't have to wait for the next release of Meteor.
One functional change: when the parent process exits, it no longer forces
all connected shell clients to disconnect, which is actually a more
convenient behavior, because it gives the clients a chance to reconnect
when/if the server starts up again, and it's easy enough to kill the
clients if that's what you want.
Saves 50MB from the extracted size of the dev_bundle/lib/node_modules
directory, previously 262MB. The entire dev bundle is 332MB extracted, for
perspective.
More importantly, since the `phantomjs` binary is not very compressible,
this change reduces the *compressed* size of the dev bundle from 71MB to
54MB, a 24% savings.
Closes#6905.
Note there are a few use cases I can think of we want to worry about:
`meteor run` -- both should be "development"
`meteor run --production` - both should be "production"
`NODE_ENV=production meteor run` - as above
`NODE_ENV=development meteor run --production` - `--production` should win
`meteor test` - NODE_ENV should be "development", buildMode should be "test"
`NODE_ENV=production meteor test" - NODE_ENV should be "production", buildMode should be "test"
Bump up the crashCount reset delay from 3 seconds to 8 seconds.
If the delay is smaller than app start-up time, then an app that
crashes at start-up will be treated as an app that crashed while
running and will be automatically restarted, and this will lead to
an infinite loop of restarting. Making the delay longer just increases
the time right after app start where a crash counts towards the max of
three restarts in a row. For example, if we upped the delay to 60
seconds, then an app that crashed in its first minute would restart but
gain a crashCount of 1, and if there were two more crashes within the
first minute of running (without another crash *not* within the first
minute to reset the counter), the app would fail to automatically
restart.
This whole mechanism is a little janky and was written way way back.
The number 3 was previously 2, but app start-up got a little bit slower.
Hopefully the number 8 will last us until this code is replaced.
writeSiteArchive already supported rebuilding in place (rather than
creating a new build directory and moving it into place; see comments
at top of builder.js), but it was not used and didn't work:
* run-app.js only passed previousBuilders to the bundler in the case
of a client-only refresh, in which case it also passed
hasCachedBundle, bypassing writeSiteArchive altogether.
* writeSiteArchive's use of previousBuilders seemingly didn't work,
because the site archive itself was never written in place, so
trying to write the targets "in place" into a brand-new build
directory didn't make sense (and threw an error).
With this change, previousBuilders are kept across all rebuilds
(not just client-only refreshes), which enables efficient, in-place
building (except on Windows, where in-place building has never been
supported), and writeSiteArchive is fixed to write the site archive
in place as well.
Previously, we would generate reports on
"Selecting Package Versions" and "Rebuild App".
- Instead of just profiling constraint solving, profile the entire
process of preparing the project via ProjectContext, by giving
each public function that "advances the stage" a Profile.run
(typically prepareProjectForBuild).
- Improve profiler output to better distinguish multiple runs
- Distinguish "Build App" and "Rebuild App"
- Instrument lots of calls that weren't instrumented before
This command builds the app with a different directory for
`.meteor/local`, including built packages and the app database. This
allows running `meteor test-app` and `meteor test` in parallel
for a given app, with DB isolation.
Also, we've changed how test driver packages work (as used for
`meteor test-packages`, like "test-in-browser"). Instead of automatically
running tests when they load, they export a `runTests` function that
you should call when you're ready to run tests.
When running `meteor test-app` or `meteor test-packages` a new additional
last line of code is added that calls `Meteor.startup(...runTests()...)`
TODO:
* Implement `testOnly` packages. The current pattern of reading a global
from `package.js` won't work for published packages, which are stored
as metadata, not code.
* Let you choose a test driver package as an argument to `meteor test-app`
* Demonstrate that a Mocha test and driver package are possible to write.
* Expose Meteor.isTest, Meteor.isIntegrationTest, Meteor.isUnitTest
* Implement `meteor test-app --unit` which only loads test files
* `meteor test-app` should load ALL *.tests?.* files, including ones
inside imports/ directories
The comments for inBareFiber claim that it's for times when you don't want
to inherit the dynamic environment variables of the current Fiber, but
none of the call sites actually relied on this behavior. Still, it may be
worth noting that async functions automatically (and cheaply) inherit the
calling Fiber's dynamics, which is virtually always what you want.
