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.
Two things:
- to determine if two versions are compatible, we need to know their ECVs. (earliest
compatible versions). If the version that we have is local, then we don't have access to the
version record of the server version, so we can't figure out its ECV. That's why in the olden
days, there was a hack to store ECVs separately ('forgotten ECVs'). The new catalog didn't
have that function implemented -- it might not need it, but in that case, it would need to make
changes to the constraint solver that might be risky at this point. In any case, implementing this
function in the new world is pretty easy and solves the problem for now.
- when we look for things, we look in the local catalog, then the server catalog and if the server
catalog can't find it, it will refresh. However, sometimes, we are looking for something that the
server catalog cannot POSSIBLY have (ie: it has a build ID). That's fine, actually, but it causes
an extra refresh on the server catalog that we don't need. I put in a break to make sure that, if we
know for a fact that the server catalog does not have a version record (ie: it has a build id), we don't
bother looking in it and just return null to begin with. That should help.
Before this fix, we were producing tarballs that npm 'tar' couldn't
untar if the first file inside the top-level directory was not
writeable. (Which was indeed the case since the unipackage -> isopack
change, which resulted in isopack.json being the first file in built
package tarballs.) See comment for more explanation.
