We now throw more specific errors, consistent between both tools and
package-version-parser (copy-and-pasted code, sadly, but we really do
have to make this check before uniload-from-checkout).
- If they're in deferred-registration state, give them their
registration link and exit.
- Before running the login prompt, mention that it's a Meteor developer
account which you can sign up for on www.meteor.com.
_.once has the problem that if you call the once'd function while it is
still in progress (re-entrantly or in another Fiber), it returns
undefined immediately. That's bad for uniload! uniload already has a
cache, so just use that. (In the future, perhaps detect an attempt to
uniload something that's currently in the process of being uniloaded in
another fiber and block until the other fiber is ready.)
Using instanceof with things you've uniloaded is a little sketchy: maybe
two different uniload calls will end up with two different copies of
Package.meteor.Meteor.Error, and it seems kind of hairy to ensure you're
not mixing and matching copies. However, Meteor.Errors are all tagged
with a string errorType, which fills me with much less fear,
uncertainty, and doubt than instanceof.
- ServiceConnection should never try to reconnect. It's already the case
that we don't hold open ServiceConnections over long periods while
idle; it makes the class much simpler if it corresponds to a single
TCP connection. This also means that as soon as we have one connection
failure (eg you're offline) we can fail instantly instead of retrying
pointlessly.
- Drop the explicit timeout code in ServiceConnection. There's already
timeout handling in stream_client, and now that we don't retry, it
actually takes effect.
- Be more rigorous about uses of Future in ServiceConnection. Ensure
that each Future is only used once (ie, avoid "Future resolved more
than once" errors). Hopefully fixes#2390.
- ServiceConnection constructor now blocks until it's connected (and
throws if there's a connection failure). Maybe this introduces a tiny
bit more latency to the connection, but it makes it much easier to
handle errors properly.
- In packageClient.handlePackageServerConnectionError, show the error
message corresponding to the connection failure.
- In Node, the (newish) error passed to the Stream callback is now a
"DDP.ConnectionError" object. We can detect this in the tool (and we
don't even need to do some complex uniload/instanceof dance, since
error classes made with Meteor.makeErrorType label themselves with a
string errorType). We also no longer have a special
ServiceConnection.ConnectionTimeoutError.
We're going to make uniload use a different flavor of "complete" catalog
soon. So we need to reduce the number of singleton-ish references to
it.
Also, we need one PackageCache per catalog, so stop it from being a
singleton too.
We were finding that npm was inconsistently including various fields (eg
"readme") in package.json, leading to spurious "must update the version
number" errors in publish-release --from-checkout. This should be good
enough, as any actual package change should also have some other file
changed!
It's a variant of publish-for-arch which uses your local source instead
of downloading it. I expect it to be good for meteor-tool (once we make
that work).
Fix a bug where shrinkwrap files weren't getting included in source
tarballs unless you were in the package directory.
