A little messy, but it will do.
The problem was with the test named "new #each binding lookup is
scoped to the template". The walk up the parentView chain was
stopping at a contentBlock when it shouldn't.
This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
Broken by each-in support.
Now we just look to see if there's an `in` in the right position in order to tell the two cases apart.
We could consider deprecating this syntax in favor of the
(now-supported) {{#each (helper arg1 arg2)}}.
#let currently re-renders the entire template when an argument
changes, so in this case:
```
<template name="spacebars_template_test_let_rerender">
<input type="text" class="foo">
{{#let y=x}}
<span class="bar">{{y}}</span>
{{/let}}
</template>
```
...when `x` changes, the input and span are destroyed and recreated.
Remove the old implementation with modifying the data context,
implement it in the new way to keep the same data context but lookup
iterator in the scope.
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)
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.
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.
