Fixes#1327
- This commit creates a shallow copy of the "options" passed to
Handlebars.compile() in order to prevent modifications
- Note that "new Handlebars.Compiler().compile(..., options)" still
modify the options object. This might change in the future, if
anybody needs a fix for that.
Fixes#1331
Due to the way, "bin"-files are distributed into the node_modules/.bin
directory on Windows, the task "test:cov" did not work on Windows.
This commit uses the node-script directly.
Closes#1341
If the @partial-block is called as parameter of a helper (like in
{{#if @partial-block}}...{{/if}}, the partialBlockWrapper is executed
without "options"-parameter. It should still work in without an error
in such a case.
Fixes#1319
Original behaviour:
- When a block-helper was called on a null-context, an empty object was used
as context instead. (#1093)
- The runtime verifies that whether the current context equals the
last context and adds the current context to the stack, if it is not.
This is done, so that inside a block-helper, the ".." path can be used
to go back to the parent element.
- If the helper is called on a "null" element, the context was added, even
though it shouldn't be, because the "null != {}"
Fix:
- The commit replaces "null" by the identifiable "container.nullContext"
instead of "{}". "nullContext" is a sealed empty object.
- An additional check in the runtime verifies that the context is
only added to the stack, if it is not the nullContext.
Backwards compatibility within 4.0.x-versions:
- This commit changes the compiler and compiled templates would not work
with runtime-versions 4.0.0 - 4.0.6, because of the "nullContext"
property. That's way, the compiled code reads
"(container.nullContext || {})" so that the behavior will degrade
gracefully with older runtime versions: Everything else will work
fine, but GH-1319 will still be broken, if you use a newer compiler
with a pre 4.0.7 runtime.
- This export will be transpiled by Babel for the cjs distribution,
but will enable others to use a pure ES6 module distribution
- Instanbul: Ignore "parser.js" for coverage reporting. This file was ignored before
via annotation, but this has no effect anymore due to the above change
- Remove istanbul annotation from `parser-prefix` (@nknapp)
Squashed by @nknapp
(cherry picked from commit 508347e)
- Multiple partial-blocks at different nesting levels
- Calling partial-blocks twice with nested partial-blocks
- Calling the partial-block from within the #each-helper
- nested inline partials with partial-blocks on different nesting levels
- nested inline partials (twice at each level)
Fixes#1252
- This fix treats partial-blocks more like closures and uses the closure-context of
the "invokePartial"-function to store the @partial-block for the partial.
- Adds a tes for the fix
Avoid duplicate // sourceMappingURL=... lines when minifying AND
generating a map. UglifyJS2 will write the line when minifying.
(cherry picked from commit 660a117)
Fixes#1284
Appearently, there is a use-case of stringifying the error in order to
evaluated its properties on another system. There was a regression
from 4.0.5 to 4.0.6 that the column-property of compilation errors
was not enumerable anymore in 4.0.6 (due to commit 20c965c) and
thus was not included in the output of "JSON.stringify".
The root cause of #1218 is that `invokePartial` creates a stack of data frames
for nested partial blocks, but `resolvePartial` always uses the value at top of
the stack without "popping" it. The result is an infinite recursive loop, as
references to `@partial-block` in the partial at the top of the stack resolve to
itself.
So, walk up the stack of data frames when evaluating. This is accomplished by
1) setting the `partial-block` property to `noop` after use and
2) using `_parent['partial-block']` if `partial-block` is `noop`
Fix#1218
Nils Knappmeier
Luiz Américo
Tobias Bieniek
Joonas Lahtinen
Travis Nelson
Lon Ingram
Kabir
Charles O'Farrell
Mr. Leo
Gennadiy Litvinyuk
Paul Falgout
Tim Wang
kpdecker
Anders D. Johnson
Ryan Lewis