- tests are not compiled with babel and must thus be in
es5
- we don't use polyfills, so we need to make sure no
functions aren't used that are not supported by popular browsers. (like Object.assign in Safari and IE11)
- Boths are errors that usually only appear when running
tests in SauceLabs, which happens only on _after_
merging a PR.
When authoring tooling that parses Handlebars files and emits Handlebars
files, you often want to preserve the **exact** formatting of the input.
The changes in this commit add a new method to the `Handlebars`
namespace: `parseWithoutProcessing`. Unlike, `Handlebars.parse` (which
will mutate the parsed AST to apply whitespace control) this method will
parse the template and return it directly (**without** processing
😉).
For example, parsing the following template:
```hbs
{{#foo}}
{{~bar~}} {{baz~}}
{{/foo}}
```
Using `Handlebars.parse`, the AST returned would have truncated the
following whitespace:
* The whitespace prior to the `{{#foo}}`
* The newline following `{{#foo}}`
* The leading whitespace before `{{~bar~}}`
* The whitespace between `{{~bar~}}` and `{{baz~}}`
* The newline after `{{baz~}}`
* The whitespace prior to the `{{/foo}}`
When `Handlebars.parse` is used from `Handlebars.precompile` or
`Handlebars.compile`, this whitespace stripping is **very** important
(these behaviors are intentional, and generally lead to better rendered
output).
When the same template is parsed with
`Handlebars.parseWithoutProcessing` none of those modifications to the
AST are made. This enables "codemod tooling" (e.g. `prettier` and
`ember-template-recast`) to preserve the **exact** initial formatting.
Prior to these changes, those tools would have to _manually_ reconstruct
the whitespace that is lost prior to emitting source.
The use of arrays was incorrect for the data type and causing problems when hash keys conflicted with array behaviors.
Fixes#1194
(cherry picked from commit 768ddbd661)
The use of arrays was incorrect for the data type and causing problems when hash keys conflicted with array behaviors.
Fixes#1194
(cherry picked from commit 768ddbd661)
fixes#1548
- add a guard to show readable syntax error for if / unless helper
- prevents against 3 different errors that can be generated by different systax errors
In 4.4.4 the block-contents was matched with an eager match, which means
that with multiple raw-blocks of the same kind, the block was spanned
over the first ending-tag until the last one.
This commit replaces this by a non-eager match.
closes#1579
* Added support for iterable object in {{#each}} helper
Currently {{#each}} helper supports either arrays, or objects,
however nowadays you can define custom iterable objects by overriding
a special method called Symbol.iterator, which results in empty result
being rendered.
* improved a test for iterables in {{#each}} returning empty result
* #each helper: using ES5 instead of generator functions in tests
* #each helper: using ES5 in the helper itself
- context.propertyIsEnumerable can be replaced
via __definedGetter__
- This is a fix specific to counter a known RCE exploit.
Other fixes will follow.
closes#1563
- The version-range above have compiler version 7 and
precompiled templates expecte the (block)
HelperMissing-functions in "helpers" and not in "container.hooks".
- Handlebars now accepts precompiled templates of version 7.
- If a precompiled template with version 7 is loaded,
the (block)HelperMissing-functions are kept in "helpers"
- The "lookup" helper could also be used to run a remote code execution
by manipulating the template. The same check as for regular
path queries now also is done in the "lookup"-helper
This commit fixes a Remote Code Execution (RCE) reported by
npm-security. Access to non-enumerable "constructor"-properties
is now prohibited by the compiled template-code, because this
the first step on the way to creating and execution arbitrary
JavaScript code.
The vulnerability affects systems where an attacker is allowed to
inject templates into the Handlebars setup.
Further details of the attack may be disclosed by npm-security.
Closes#1267Closes#1495
- 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#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.
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".
Nils Knappmeier
Robert Jackson
kpdecker
Hannah Wolfe
Nils Knappmeier
sohibe
antelle
Joonas Lahtinen