The server sends hot code push updates to mobile clients with ROOT_URL
and DDP_DEFAULT_CONNECTION_URL taken from the MOBILE_ROOT_URL and
MOBILE_DDP_URL environment variables. These are set by the main meteor
process when it starts the app runner.
* --port now requires a port ('meteor run --port example.com' isn't valid).
* --mobile-server defaults to your detected IP address and the port from
--port.
* If you provide a value for --mobile-server, we default to http:// as
the protocol. A host is required for --mobile-server if you don't omit
the option entirely. Similar for the --server argument to 'meteor
build'.
This commit includes the 'netroute' npm module as a core package (which
has binary dependencies) for IP detection. It would be nice to put it in
packages/non-core, but I think it has to be a core package in order to
uniload it.
When publishing a core package, you’re allowed to omit version numbers in package.js. With this change, we determine the correct versions of all the dependent packages based on the current checkout, and we send them to troposphere (instead of core packages having “null” constraints on their dependencies).
We throw an error if you have any missing version constraints on your package dependencies and you are not using versionsFrom or publishing a core package from a checkout.
We’ve already fixed this (no constraints on core package deps) retroactively in troposphere.
It speeds up the constraint solver by orders of magnitude when publishing a package.
When publishing a core package, you’re allowed to omit version numbers in package.js. With this change, we determine the correct versions of all the dependent packages based on the current checkout, and we send them to troposphere (instead of core packages having “null” constraints on their dependencies).
We throw an error if you have any missing version constraints on your package dependencies and you are not using versionsFrom or publishing a core package from a checkout.
We’ve already fixed this (no constraints on core package deps) retroactively in troposphere.
It speeds up the constraint solver by orders of magnitude when publishing a package.
This timeout was designed for a very specific case (hit stop during a
hot code push, come back to the page later and you don't expect your
session state to still be there), but it's not clear what length of time
is right for that, nor whether it's even what users expect (and if there
should be a timeout, it probably varies from package to package
depending on what type of data the package is storing in sessionStorage
-- e.g. for OAuth logins, 30 seconds is way too short of a timeout).
Fixes#2696.
This timeout was designed for a very specific case (hit stop during a
hot code push, come back to the page later and you don't expect your
session state to still be there), but it's not clear what length of time
is right for that, nor whether it's even what users expect (and if there
should be a timeout, it probably varies from package to package
depending on what type of data the package is storing in sessionStorage
-- e.g. for OAuth logins, 30 seconds is way too short of a timeout).
Fixes#2696.
