I think we hadn't done this for back-compat reasons, however it doesn't make sense as it means that test-drivers and test utilities can't be `testOnly` if they want to be usable for `meteor test-packages`. Which kind of makes it pointless to have `testOnly`.
I don't anticipate it will cause problems, but I'm not entirely sure.
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"
Our old "unit" test mode didn't really enforce "unit-ness" and was perfectly capable of running integration test. So it was confusing to call the two modes unit and integration test modes.
Instead, we call them "test mode" and "full app test mode", run with `meteor test` and `meteor test --full-app`.
The rules for test files were also simplified -- simply *.test[s].* for test mode, and *.app-test[s].* for full app tests. `tests/` directories are simply ignored again.
You can now run `meteor test-app --unit` to load just test files
and their dependencies.
Also, `Meteor.isIntegrationTest` and `Meteor.isUnitTest` are now
available on the client side of your apps. This can be used to
only run some tests in either mode.
TODO: Find unit tests inside imports/ directories even if they're
not explicitly imported.
Note that `export default` no longer modifies `module.exports`, but simply
defines `exports.default`, so these two import styles will work:
import DefaultExport from "./export-default-module.js"; // preferred
var DefaultExport = require("./export-default-module.js").default;
but this style will no longer work:
var DefaultExport = require("./export-default-module.js");
