If you Blaze.remove a View that is a template rendered by Blaze.renderWithData, or included with an implicit “with” as in `{{> myTemplate someData}}`, Blaze will now remove the DOM of the template, and also remove the implicit “with” (in both cases).
As background, Blaze.remove only works on Views that were attached directly under a DOM element, not inside another View. Blaze.render always attaches the resulting View directly under a DOM element, but Blaze.renderWithData creates a “with” View around the template View. Previously, you could Blaze.remove the “with” View (which is returned by renderWithData), but if you got access to the template’s View some other way and tried to remove it directly, nothing would happen. Now, the correct thing happens (the View is destroyed and the DOM is removed).
In the future, we should consider whether Blaze.remove should work on arbitrary Views, not just Views attached under a DOM element.
This commit fixes a 0.9.3 regression where the calculation of the
topLevelPrereleases object was not updated with the introduction of
disjunction constraints (||) and would always be empty.
topLevelPrereleases and useRCsOK are merged into a single
anticipatedPrereleases option which is now passed in to the
constraint-solver package rather than constructed inside it. (This
object will also be used in ProjectContext as part of PackageDelta
calculation.)
The usedRCs return flag is now called
neededToUseUnanticipatedPrereleases.
There were too many things called `constraints` — ConstraintsList objects, arrays and maps of Constraint strings or objects… Also “alternatives” is already taken, so use “disjunction.” Consider propagating this rename upstream to package-version-parser, since it’s kind of weird that “constraints” is implicitly a disjunction (rather than, say, a conjunction).
Don’t call a constraint string a version string.
When it comes to pre-releases, Constraints aren’t “context-free.” That’s ok for now, but at least hoist the pre-release check out of the innermost loop. Ideally we’d hoist it higher, but I can see that it’s pretty convenient this way.
Should be identical in behavior to before (differing maybe in some super edge case, but I doubt it).
