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.
* Auto-install `meteor self-test` dependencies upon use.
This uses the same new facilities which were created for auto-installing
Cordova (#8976) to also auto-install PhantomJS and BrowserStack WebDriver npms
into their appropriate home in the dev bundle when they're needed for running
self-tests.
* Use a more descriptive name for the reference to the `require`-d npm module.
This reverts commit 4d37a05fb3.
After git bisecting between origin/release-1.5 and origin/release-1.5.2, I
identified this commit as the culprit in recent failures of the modules
test app: https://circleci.com/gh/meteor/meteor/4857#tests/containers/3
Note that the modules test app seems to be failing only on Linux, and it
does pass reliably with this commit reverted. It must have something to do
with Mongo failing to start, and thus the "App running at" message never
appears, but I don't have a good theory why that might be.
The command to run just the modules test app is
meteor self-test --history 1000 'modules - test app'
@zimme @hwillson @abernix any ideas?
* Include the Node.js and npm version in the `star.json` manifest.
This makes it possible to know exactly which version of Node.js and npm
were used by the `meteor` command from which the bundle was built from.
* History.md for #8956.
This Cordova `ensureDevBundleDependencies` function will utilize a another
method called `ensureDependencies` which checks to see if a module can be
resolved by the tool. If it cannot be resolved, it will install it using the
`installNpmModule` facilities of `meteor-npm.js` in the same way as other npm
packages within packages, except with the destination as the `dev_bundle`.
This commit also adds a couple of previously not explicitly installed npm
modules which Meteor requires directly: `cordova-registry-mapper` and
`cordova-common`. Both of these were previously relying on npm package hoisting
which previously occurred during the installation of `cordova-lib` in the dev
bundle which happened under the supervision of a `package.json` file (which is
later purged).
When `cordova-lib` is installed directly, without a package.json, the
aforementioned packages are not hoisted to the top level, but instead reside
inside `cordova-lib`. This is less than ideal since we're relying on the API
of an indirect dependency of `cordova-lib`.
This will enable the possibility of deferring the installation of the Cordova
modules (e.g. `cordova-lib`, `cordova-common`) until a time deemed appropriate.
