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.
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.
It can be used to get things like `path` (though you can just use '/'),
but trying to require the packages whose list is determined by running
the file while running the file just doesn't make any sense.
Note that "backport" here doesn't just mean "patch release"; it means
"patch release to a release that was not the newest release" (ie, an
out-of-order entry in history)
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.
