This fixes a regression caused by 88d43a0f16 which is demonstrated in meteor/meteor#7849.
Essentially, with the current implementation some Cordova build elements are "stale" when the build is copied. For example, if you execute a `meteor run ios` and then `meteor build . --server=http://example.com/` (note: `example.com`) the `config.xml` (`<access origin />`), the boilerplate HTML (`__meteor_runtime_config__`) and other elements of the bundle (`Info.plist` on iOS) will still contain the previously used `http://<local_ip>:3000` address instead of `http://example.com` as they should.
Additionally, it would appear that it's impossible to actually checkout a project and immediately run `meteor build` without running `meteor run (android|ios)` first.
Various work-arounds for this seem to exist, such as running `meteor build` twice, or running `meteor run --server=http://production.com` first.
Ultimately, this is occurring because the bundle is being copied before the Cordova `prepareForPlatform` occurs which I believe was not intended.
There is already a test in place which fails without this fix, but marked as `slow` and therefore not executed on CircleCI. Specifically, `cordova builds with server options` would have caught this. Forcibly running this test locally now passes with this change.
Fixesmeteor/meteor#7849Fixesmeteor/meteor#7291Fixesmeteor/meteor#6756
Although I have said I do not think Meteor should run `npm install`
automatically to update application node_modules, my real concern is that
Meteor should not interfere with your preferred node_modules-related
workflow, be it npm, npm-shinkwrap.json, yarn, yarn.lock, checking your
node_modules into git/mercurial/cvs, or whatever other scheme you have.
Automatically installing node_modules from the default package.json file
when a new app is created will eliminate real confusion, and should not
interfere with any workflows, because there is no opportunity to establish
another workflow before Meteor runs `npm install` the very first time.
Scaffold an official project structure
Add --bare option to meteor create
Notice scaffold options on meteor create
add full skeleton
add spaces
remove shell-server package from skew-full + add description of new packages
Add --bare option to meteor create
Notice scaffold options on meteor create
add full skeleton
add spaces
remove shell-server package from skew-full + add description of new packages
improve PR
resolve conflict
Fix rebase
fix static-assets readme
Fix tipo
Remove insecure and auto publish packages
Remove useraccounts-configuration.js
add tests
fix PR
Tests were broken by the new dependency on the babel-runtime npm
package, but fortunately all those tests run `meteor --prepare-app`
whenever an app is created by a self-test, so this change should fix
most of the breakages.
At this point, the only dependencies installed in this way are
babel-runtime and meteor-node-stubs, but that set of packages will
expand in the future as we move more dependencies to npm.
Because the cache directories are shared instead of copied, the results
now have a chance of surviving multiple invocations of `meteor test`.
This significantly reduces rebuild times when testing a large app; for
example, the meteor/tools/tests/apps/modules app now takes less than 10
seconds to rebuild (after restarting the process, not after a file change)
instead of 60 seconds or more.
Because the cache directories are shared instead of copied, the results
now have a chance of surviving multiple invocations of `meteor test`.
This significantly reduces rebuild times when testing a large app; for
example, the meteor/tools/tests/apps/modules app now takes less than 10
seconds to rebuild (after restarting the process, not after a file change)
instead of 60 seconds or more.
"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"
