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.
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.
Prior to this change, a dependency was registered on
`Template.instance` when wrapping a helper, rather
than when it is called. This caused templates to get
re-rendered more frequently than necessary as caught
by a test failure, and probably many other bugs.
Also allow accounts-password email templates to set mail headers, and
for the From override to be a function rather than a constant.
Fixes#2858. Fixes#2854.
Fill in all packages without README.md files with a short
README.md mentioning that this is an internal Meteor package.
Break up the top paragraph of a couple of existing README.md
files to be proper long description.
There is more work to do here, involving line wrapping and the like.
You can still include them on the client, but they don’t work in
Safari 4 and IE 8 because semver.js uses ES 5 methods including
String#trim, Array#map/filter/forEach, and possibly others.
This should fix any unit test failures in these packages.
In Session.close, `self.socket.close` could trigger this event handler:
socket.on('close', function () {
if (socket._meteorSession) {
Fiber(function () {
socket._meteorSession.close();
}).run();
}
});
which could trigger a reentrant call to Session.close. The self.inQueue
guard was not sufficient to stop multiple execution, because it was too
low.
Symptoms included:
- The "sessions" server fact would be decremented twice and become
inaccurate (and even negative!)
- Connection.onClose callbacks could be called twice
Fixes#3331.
In Session.close, `self.socket.close` could trigger this event handler:
socket.on('close', function () {
if (socket._meteorSession) {
Fiber(function () {
socket._meteorSession.close();
}).run();
}
});
which could trigger a reentrant call to Session.close. The self.inQueue
guard was not sufficient to stop multiple execution, because it was too
low.
Symptoms included:
- The "sessions" server fact would be decremented twice and become
inaccurate (and even negative!)
- Connection.onClose callbacks could be called twice
Fixes#3331.
