I found this entire file of commented-out self-tests. The
version-parsing part seems out-dated now, but there are tests of
utils.defaultOrderKeyForReleaseVersion in there that seem legit, which
I re-enabled.
In the return value, `name` has been changed to `package`,
and `vConstraint` is now `versionConstraint`.
`constraint.package` is better than `constraint.name`, where
`constraint` is a PackageConstraint. It's also more consistent
with functions like parsePackageAtVersion which return an object
like `{package, version}`.
`vConstraint` was too cryptic.
Changes were discussed with Glasser in a code review.
Troposphere does not call parseConstraint or work with constraint
objects, so it doesn't need to change.
This is a breaking change to the package-version-parser API (or one
method of it, at least), but it is considered an internal API so we
are not worrying too much about it.
Summary:
Previously, the MongoConnection constructor (which gets called
implicitly the first time you make a Mongo.Collection) would wait for a
successful connection before returning ... if an oplog URL is supplied.
If not in oplog mode, it would return before the connection is
successful, and the first subsequent calls that actually tried to do
something with the DB would block instead.
Having an inconsistent API that is sometimes sync and sometimes async is
not very clear. Moreover, error handling from connect was strange.
Prior to 0.8.1 (24a0006c), connect errors would be thrown
uncatchably (ie, from an unrelated context). Starting with 0.8.1,
connect errors would effectively be ignored due to the new
bindEnvironment (they'd be logged, but all code would continue
normally).
It's pretty important that startup connection errors crash the server
process instead of letting it keep running unproductively. And it would
also be nice if those errors could be caught (if you're making a
MongoConnection in your own code). So this change ensures that
connection errors get thrown by the MongoConnection constructor.
Fixes#3038.
Test Plan: new unit test. manual test with MONGO_URL=xxx
Reviewers: ben
Subscribers: justinsb
Differential Revision: https://phabricator.meteor.io/D19
Summary:
What I'm looking for here is: attention to the few parts that aren't just
deletions (eg in auth.js), and thoughts about if removing any of these things
might break systems I haven't thought about.
Test Plan: test-packages, self-test (which mostly passes)
Reviewers: ekatek
Differential Revision: https://phabricator.meteor.io/D18
Nothing ever made full use of the promise of the complexity of the
API (configuration that can change at runtime) anyway.
This includes completely ignoring the $APP_CONFIG variable.
I opened GitHub issues against the only Atmosphere packages that had
dependencies on application-configuration (none of which actually used
the package other than by declaring the dependency).
Also remove SIGHUP handler. This was designed for a legacy system, and
SIGHUP would be a better fit for what autoupdate currently uses SIGUSR2
for. This includes removing some code in the ddp server to close
sockets on SIGHUP.
See #3532.
We honestly should probably just drop the option and allow you to type
either a username or a password, just like in accounts-ui.
Because options have to be consistently bool or not across commands (so
that you can put them before the command name), change the testing-only
dummy command's string option to a different nonsense name.
A recent change fixed the behavior of `Template.currentData`
and `Template.parentData` in event handlers and helpers.
These are tests for the new, correct behavior.
(The old behavior read the data of the template instance.
The new behavior read the data context around the DOM node
where the event or helper ran)
Since the browser application cache appears not to support URL path
routes in a non-buggy way (see
https://github.com/meteor/meteor/pull/2926), applications using the
appcache package will want to use hash fragment routes instead.
This PR adds support to the spiderable package for hash fragment
routes. An original URL such as `http://example.com/#!a=1&b=2` will
be encoded by a search engine as an escaped fragment, decoded by the
spiderable package, passed through to the phantomjs process, and
appear to the phantom client as `#!a=1&b=2` in `window.location.hash`
(the same as when the original URL is opened in a regular browser).
A previous change decoupled "current view" from "current template instance".
The code made sure to preserve "current view" explicitly within
`this.autorun`, but now we need to do the same for "current template instance"
The server-side Meteor.call abstraction is "RPC", not "function call",
so you shouldn't be able to mutate internal state using it. This is a
similar change to that done in e91713d9 with function parameters.
Fixes#3201.
