This is performance-sensitive code, and I think this extra (uncached) call
to files.statOrNull could be contributing to test timeouts on Circle CI.
Follow-up to #9030.
As outlined in #3854, if `meteor --settings` points to a
directory instead of a file, an application gets caught up
in an infinite rebuild loop. Since it was assumed only a
file would be configured via `--settings`, a file watcher
is created for the specified directory, and that watcher
is then triggered ad infinitum.
These changes prevent a file watcher from being created
on a `--settings` directory.
If a login token is expired, or no longer valid, make sure that Meteor doesn't
just sit there at a login prompt that the user can't see.
This currently only applies if `headless` mode is enabled, though a follow-up
to this commit might consider setting `headless = true` automatically
in a CI environment using environment variables such as: `CI`, `TRAVIS`,
`JENKINS_URL`, etc., as the npm-registry-client does in a similar way.
See: https://github.com/npm/npm-registry-client/pull/129/filesFixes#8839.
Should fix#8988 and #8942.
Now that #8866 is the default behavior, it can take up to 5000ms for
changes to files modified during the build process to be noticed.
Before #8866, when we called e.g. files.writeFile(path), a native file
watcher would notice the change immediately, almost always before the
build process read the file again. This was definitely racy, but we were
getting away with it consistently... until #8866.
I was able to reproduce the problem in #8988 by running
echo some-local-package-name >> .meteor/packages
in an app with a local package of the given name. After debugging the
endless rebuild cycle, I found that .meteor/versions was being rewritten
by files.writeFile during the build process, but the file watching system
was not noticing the change in time to prevent watch.isUpToDate from
returning true. The change was finally detected when restarting the
Watcher responsible for .meteor/versions, which of course triggered
another rebuild, so the same problem kept happening again and again.
The modules test app appears to be running with process.env.NODE_ENV equal
to "production" on Circle CI: https://circleci.com/gh/meteor/meteor/5030.
Enabling this transform in production as well as development is fine
because we primarily want to test that plugins from the "env" section of
.babelrc are respected, regardless of the value of process.env.NODE_ENV.
Using different plugins in production might be worth testing, too, but
that's less critical.
Follow-up to #8963.
The increased mongo connection timeout in 522d86dc4e
means that the we can decrease the "modules - test app" self-test
application start-up wait internval significantly (since mongo
will now start properly and the self-test can continue).
Certain self-test's like "modules - test app" are encountering
mongo connection timeout errors on some runs. Increasing the
connection timeout helps address these errors.
