"universe" was an old attempt to allow you to run various MDG
servers (Meteor Developer Accounts, the package server, an old version
of the Galaxy deploy server, etc) on localhost and configure the tool to
talk to it not via a bunch of environment variables but via a file
called "universe" at the root of your checkout. Nobody uses this (and
most of the URLs have environment variables for them anyway). Simplify
the code by removing this entirely.
Also remove some more dead code, and a test that claims it only runs if
you have universe set up.
The `test` mode wasn't passing the proper proxyHost and proxyPort values to runAll. This changes the behaviour to work the same as the regular `run` mode and also adds tests for both modes to test the bindaddr (localAddress) is taking effect properly.
Fixesmeteor/meteor#6961
Building the iOS app for release should be done from Xcode anyway, to
correctly code sign and submit to TestFlight or the App Store.
Because building would override `build-extras.xcconfig`, this would
remove a temporary workaround for #6492, which is now correctly applied
on both `meteor run` and `meteor build`.
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.
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
If $METEOR_BINARY_DEP_WORKAROUND is set, then when bundling for a
non-host platform (build/bundle/deploy commands only), if a package has
no server unibuild for the target architecture, use the host
architecture and replace the npm modules with a package.json and
npm-shrinkwrap.json. Also write out a top-level setup.sh script (inside
programs/server) which runs npm install in all such directories.
To support this, we make sure to save the package.json and
npm-shrinkwrap.json files in various intermediate directories in case we
need them later. (We put them inside node_modules because that is what
gets copied from source tree to isopack.)
