ie, make it prepend METEOR@ if necessary.
(We DON'T do that in the pre-springboard call in main because that one
might be telling us to springboard to a pre-0.9.0 release!)
Solves a bunch of issues like the previous commit where, if
.meteor/release just says "0.9.4", you get weird behavior.
We don't want it to be the first thing we link to on the wiki.
It's also nice if it comes last in the checklist, as it's the most likely thing
for users not to have.
Otherwise:
$ meteor
meteor
[[[[[ /private/tmp/p107 ]]]]]
=> Started proxy.
=> Started MongoDB.
=> Started your app.
=> App running at: http://localhost:3000/
Your app has been updated to Meteor 1.0-rc.7 from Meteor 1.0-rc.7.
Restart meteor to use the new release.
Affecting factors:
- requested platforms
- platforms added to the project
- installed SDKs
- if platform is available on system at all (e.g. iOS is not available on linux)
- if it is build or run (should the errors be ignored or not?)
Reality is actually a little more complicated than this:
* We use your automatically detected local IP if you are running on device.
* We use 'localhost' if you are running on a simulator.
But it's hard to fit that in help text, and this is at least closer to
reality than it was before.
For some reason, super-jobs of the actual upload job have a `.current` progress but no `.end` value, and then they are chosen for progress display instead of the actual upload. With this change, we don’t eagerly choose a job for display if it has a `.current` unless it also has a `.end`.
It’s probably also worth examining what is going on with the various values of `.current` of the super-jobs.
If we use `__meteor_runtime_config__.ROOT_URL` directly, as we were
previously, then we end up sending Cordova clients to http:// URLs even
if force-ssl is being used in the app. This is fairly bad on its own
(always sending cordova clients to http:// URLs instead of https://),
but made even worse by the fact that we don't set CORS headers on
force-ssl redirects (that is, the app breaks completely if the client
makes a DDP connection to an http:// URL for a force-ssl app).
Previously, all progress display was turned off after the app’s initial start, so no progress would be displayed on restart due to server code change.
Now, we enable/disable progress display from inside the loop that re-runs the app on change.
Remove the “suppressDisplay” approach to hiding the spinner when there’s an error building the app, because it didn’t work on rebuilds, only the first build. Better to just call enableProgressDisplay(false) and hope for the best like we do elsewhere.
Conflicts:
tools/progress.js
Previously, if there were two parallel jobs like “Starting your app” and “Bundling app,” we’d display just a spinner and no message. Now, we choose a message and display it.
(…due to a server-side code change)
Restarting the server can take a while (30 seconds for one particular app), so it’s nice to at least print when we start doing it. Soon there will be progress displays during it, too (when we add more of them to `meteor run`).
We lose the opportunity to coalesce server restarted messages, as in `Meteor server restarted (x2)`, but adding any sort of progress display also does that.
