sub, sup, bold and small helpers undocumented?

[AndrewLeedham]

I recently came across some weird behaviour where the template {{#url}}{{small}}{{/url}} when passed the data { url: 'https://google.com' } wraps the url in small html tags, initially I thought this is just built-in helpers, but looking at the docs it is not documented as one. Furthermore, when logging the built-in helpers and partials small is not referenced anywhere, I also found the same to be true for sub, sup and bold. Searching the codebase for these terms also yields nothing. I am left very confused. Where is this behaviour coming from? and is it possible to turn it off?

I wrote a little JSFiddle to demonstrate the issue: https://jsfiddle.net/d0ve69xL/

[nknapp]

I think, this works because bold is a function on String.prototype.

console.log("test".bold()) // "<b>bold</b>"

[AndrewLeedham]

Ah yes, looks like that is it.

This seems like an unintended side effect?

[AndrewLeedham]

@nknapp happy to put in a PR if you can point me in the right direction?

[nknapp]

Unintended? Probably. But it also works and I don't know who relies on it working.

We can change it in 5.0, but not in 4.x
In 4.x, we could make a switch and turn the default value in 5.0 this is something I wanted to do for security reasons anyway.

I would make it a runtime option (boolean flag)
It needs to be changed in the nameLookup function of the compiler and in the lookup helper.

The difficulty is that old templates need to work with the current runtime and vice versa.

[nknapp]

I tried this in #1594 but decided to create a simpler solution first.

[nknapp]

I'd like to know why the behaviour is a problem for you.

[AndrewLeedham]

I am trying to progressively convert a project from mustache to handlebars. One of the partials that is used a lot is the button which wraps the template in a url if (mustache style). So I end up with a template loosely like this:

{{#url}}
<a href="{{url}}" class="{{#small}}small{{/small}}">
  text
</a>
{{/url}}

Since small is a function by default, if just url is passed the small property is always Truthy, whereas it would be undefined in mustache.

[nknapp]

And mustache does not resolve prototype properties?

[nknapp]

I'm just wondering: One of the major features of Handlebars was its mustache-compatibility. I just wonder why this has never occured before and why this case isn't caught by the mustache-testcases that handlebars runs against in each build.

[AndrewLeedham]

Mustache does not resolve the prototype properties no:

• mustache: https://runkit.com/embed/w8dfurz5q3nc
• handlebars: https://runkit.com/embed/ftxfy79ju90z
• handlebars (compat mode): https://runkit.com/embed/csu8s7adql2q

[nknapp]

I think it is not that easy to implement this check correctly. It should be a runtime option, but because compiler and runtime must remain compatible in 4.x, we cannot just add a function to the "container" object in the runtime that performs the check. If the compiled template calls the function and it is not there because the runtime is older than the compiler, then people will complain (I made that mistake already).

In 5.0, that would be OK, but still, the "lookup"-helper does not have access to the "container" and cannot check the runtime option. And the "lookup"-helper should behave equally to a direct lookup.

I have plans for releasing a 5.0 version. Apart from code-cleanup, this this a feature I wanted anyway, for security reasons. It would be great if you start it.

• Compiler: https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/compiler/javascript-compiler.js#L17
• Runtime:
  • "container"-object that can be accessed from the compiled template and could get a "allowedProperty" method based on "hasOwnProperty" or something like that: https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/runtime.js#L109
  • Maybe this is the place to exchange the "lookup" helper based on the runtime option: https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/runtime.js#L229

[AndrewLeedham]

What is the roadmap for 5.0 is there likely to be an alpha/beta version anytime soon? Is it feature complete, would it be plausible to use in a development environment?

[nknapp]

My plan for 5.0 is to

• publish the changes that are currently on the master branch Move main development back to master-branch #1566,
• bump webpack and babel to the current versions (which is not trivial and may cause breaking changes)
• disallow access to prototype properties

My main motivation is to go back to the master branch and eliminate the other two pain points.
I cannot give you an exact timeline, though, because I work on the project only when I have time to do so. But that is also true for the 4.x branch.

[nknapp]

Disallowing prototype access is released in 4.6. This issue should be fixed now.