In 5.0.0 Cordova now requires a whitelist plugin for allowing access to external resources.
For now the dependency is for the legacy-whitelist plugin due to meteor currently using
the older <access> tags.. see https://github.com/apache/cordova-plugin-whitelist
Previously we were carefully cloning the relevant pieces of most
modifier $ops but not for replacement (or for $pushAll, for that
matter). Instead, just clone the full mod doc always.
(The purpose of cloning here is so that mutable state isn't shared
between the arguments to minimongo APIs and internal LocalCollection
data structures.)
Fixes#4377.
self.declaredExports is always true since 0.9.0 (it comes from a _.pluck
in compiler.js) but test slices have their own package
name (local-test:*) so it's OK.
Resolves discussion of how {{@index}} is tokenized:
* BlazeTools.parseExtendedIdentifierName parses @identifier
* @identifiers are treated normally, except an error is thrown
if one ever doesn't resolve to a non-nully value (so that
users get a real exception when they try to use an unsupported
directive like @first)
See discussion at afd240fa6f
`Spiderable.requestTimeout` can now be changed in server code in an app
to the number of milliseconds to wait until spiderable gives up on
phantomjs.
This is motivated by frontpage hitting 15 seconds at times (due to some
other problem we have), but regardless slow page loads are better than
non-crawlable ones.
There's an argument in favor of making AccountsClient available on both
client and server, since server code might need to act as a client to an
accounts server, too. I don't need that functionality yet, but it's
something to think about.
Note that this constructor inherits from the AccountsCommon constructor.
Naturally both of these constructor functions should become classes once
we have support for ES6 classes.
The static analysis is used to determine what "var"s need to be
automatically inserted by the linker at the package level. But for app
code, we never actually insert these vars, since apps run in "global
namespace" mode. So it's a waste of time to run the static analysis at
all.
The #1 goal is to not say, "Your packages are at
their latest compatible versions" whenever an
update has no effect. That isn't necessarily
true. `meteor update` with no arguments never
updates a major/minor of an indirect dependency,
for example. Also, you may have specified some
packages on the command line (though arguably
"your packages" could be interpreted to refer to
those packages).
In addition, `meteor update` with no arguments now
reports any direct or indirect dependencies that
aren't at their latest versions.
For example:
```
Your top-level dependencies are at their latest compatible versions.
Newer versions of the following indirect dependencies are available:
* aldeed:collection2 0.1.7 - 2.3.3 is available
To update one or more of these packages, pass their names to `meteor update`.
```
Sort of related to #4170.
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)}}.
The option “prompt” takes precedence over “forceApprovalPrompt”.
Valid options for “prompt” are “consent”, “none”, “select_account” or a
combination. i.e. “select_account+consent”.
We fixed the stack overflow in Blaze materialization by using
a "work stack" pattern instead of recursing.
Putting local variables on the heap hurts readability and doesn't
help performance; it was just saving us 16 bytes or so (or whatever
two local variables is) per nested View.
#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.
