Closed knight-dj-et closed 9 years ago
we have a number of issues about this already, add your comment to one of those.
If by number you mean 2, then yes. However, I have reviewed both of them and neither of them directly relate to the issue outlined above. The primary issue is that a major release of Handlebars was included in a minor revision change of assemble-handlebars (and thus automatically included in the current version of assemble).
assemble-handlebars@0.2.6
is now back to using handlebar@1.3.0
so assemble@0.4.x
will be using the old version. also, we're moving old assemble code for use in grunt to grunt-assemble
. grunt-assemble@0.2.x
is using assemble-handlebars@0.2.6
and grunt-assemble@0.3.0
is now using assemble-handlebars@0.3.0
which has bumped Handlebars to 3.0.1
.
between 0.2.3 and 0.2.5, the version of handlebars used in assemble-handlerbars went from ~1.3.0 to ^3.0.1. Since assemble-handlers is a fairly thin wrapper around handlebars specifically for connection to assemble (which version 0.4.42 includes assemble-handlebars at version ^0.2.3), the change in handlebars versions (a significant change, which by the guidelines of semvar can include breaking changes) is automatically picked up when assemble@0.4.42 is included.
In this particular case, I have found where handlebars does not seem to handle a particular case in the same way as earlier versions did. I have confirmed that none of the code above handlebars has changed.
Essentially, I have several markdown files whose layout is specified by the assemble config. In each of these files, I have YAML front matter with a property called data, which is pulled from a .json data file using loDash templates.
Example (for "foo.md")
In the case that
foo
is not a property defined inreference
(different thanundefined
), it now errors in a very unclear manner ("Cannot call method 'replace' of undefined Use --force to continue") whereas under Handlebars 1.3.x, it did not (and everything successfully built).