- grunt -> 1
- grunt-contrib-watch -> 1
- mocha -> 5
- in common.js: define "global" , see mochajs/mocha#1159
- in builtins.js: revert "console.log" to old value just
after using the mock (in log-helper tests), because
mocha calls "console.log" on failure, before
"afterEach"
closes#1391
uglify-js is an optional dependency and should be treated as such.
This commit gracefully handles MODULE_NOT_FOUND errors while loading
uglify.
- Check for existing uglify-js (and load uglify-js) only if minification
was activated
- Use "require.resolve" to check if uglify exists. Otherwise, a missing
dependency of uglify-js would cause the same behavior as missing
uglify-js. (Only a warning, no error)
- The code to load and run uglify is put into a single for readability
purposes
- Tests use a mockup Module._resolveFilename to simulate the missing module.
This function is used by both "require" and "require.resolve", so both
are mocked equally.
(cherry picked from commit d5caa56)
Closes#1233
- Handle path-separators properly. Use "path.sep" instead of "/".
Or use "require.resolve()" if possible
- Use "execFile" instead of "exec" to run the Handlebars executable.
This prevents problems due to (missing) shell escaping.
- Use explicit call to "node" in order to run the executable on Windows.
- Add "appveyor"-CI in order to run regular tests on Windows.
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.
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.
- 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
Allows for ] literal characters to be used within [] IDs by prefixing them with the \ character. `\` literal at the end of the may be referenced by the `\\` sequence if conflicting. Under most circumstances the `\\` sequence will continue to work.
Potentially breaking change for users of [] ids that have `\\` anywhere in the id or `\` at the end of the id.
Fixes#1092
If a decorator is used within a partial but not in the calling template, the hash is not passed in. For now error on the side of always including as just assigning values has minimal overhead.
Fixes#1089
Allows for partials to be defined within the current template to allow for localized code reuse as well as for conditional behavior within nested partials.
Fixes#1018
These allow for a given block to be wrapped in helper methods or metadata and allow for more control over the current container and method before the code is run.
This allows for failover for missing partials as well as limited templating ability through the `{{> @partial-block }}` partial special case.
Partial fix for #1018
There is no real need for us to do `.call(container` other than for backwards compatibility with legacy versions. Using the 4.x release as a chance to optimize this behavior.
Nils Knappmeier
Joonas Lahtinen
Lon Ingram
Charles O'Farrell
Ryan Lewis
kpdecker
Mark Christian
Dennis Kuczynski