* Add mongo-dev-server package
Only start the MongoDB server if this package
is present in the project.
* Small layout/formatting adjustments; updated README.
* Allow tests using fake-mongod to start (fake) Mongo.
* Adjust test stdout matching to be less sensitive to ordering.
* Add `mongo-dev-server` History.md entry.
* Remove mongo start check since the tested for error prevents mongo startup.
* Remove README traling whitespace.
* Bump mongo package version.
* Add mongo-dev-server package
Only start the MongoDB server if this package
is present in the project.
* Small layout/formatting adjustments; updated README.
* Allow tests using fake-mongod to start (fake) Mongo.
* Adjust test stdout matching to be less sensitive to ordering.
* Add `mongo-dev-server` History.md entry.
* Remove mongo start check since the tested for error prevents mongo startup.
* Remove README traling whitespace.
* Bump mongo package version.
When checking the `entriesByIno` Map to see if an `entry` already exists for
the specified inode, also check to make sure the found `entry` is only
re-used if the current file watcher path matches the returned path. This
makes sure new file watchers are created for moved files (so files with the
same inode), instead of attempting to re-use a file watcher that's watching
an invalid path.
* Fix CircleCI failures by adjusting the timing of problematic tests.
* Wait longer for Mongo to start.
* Increase lint wait time; run logs show we're close to the current timeout.
The pull request corresponding to our fork is not going to be merged, so
it's better to use the alternative this.finished API available in newer
versions of the upstream package.
https://github.com/williamkapke/node-eachline/pull/4
With Meteor 1.6 / Node 8, I noticed _buildLocalPackages taking multiple
seconds on initial server startup and restart, and the problem seems to be
that we call the global.gc function too often. This wasn't a problem in
previous versions of Node, as far as I know, but it makes sense to heed
the comment in tools/utils/gc.js, now that it matters.
Though they don't appear to actually be used anywhere by Meteor, it's
probably worth preserving them in case they are somehow exposed
elsewhere. Static class properties would avoid this, but the TC39
proposal is still progressing.
This restores the behavior of 8c70716954 by
default, with the option of disabling the prioritized file watching system
by setting METEOR_WATCH_PRIORITIZE_CHANGED explicitly to "false".
The self-tests where the environment variable is explicitly set form a
nice to-do list of tests that should be improved to be more robust to cope
with differences in file watcher timing.
Helps with #8648 and similar issues.
Although I think 8c70716954 is a good idea
in practice, it altered the timing of self-tests enough to cause a number
of failures, so for now that behavior will be gated behind the environment
variable METEOR_WATCH_PRIORITIZE_CHANGED.
