Julian Gonggrijp commented on issue #85 at Julian Gonggrijp / Wontache

Julian Gonggrijp
2025-12-17T11:36:44Z

Thank you for reporting this, and sorry for the slow reply. I have not yet found a good way to manage notifications from GitLab.

My initial thought was that this might be hitting an edge case in the spec. There is a spec that states that a final newline should not be required,

https://github.com/mustache/spec/blob/97c05b0652f06ef4cbe12016b8d0e41df31c4b05/specs/partials.yml#L82-L87

but there is also a spec that states that surrounding whitespace should not be affected:

https://github.com/mustache/spec/blob/97c05b0652f06ef4cbe12016b8d0e41df31c4b05/specs/partials.yml#L54-L59

Wontache passes all specs, including these two, so at first, I thought the observed behavior might be an (ugly) side effect of these two specs interacting. However, I did feel that the specs didn't give a conclusive answer. I also consulted spec#130, which is foundational for the current whitespace handling rules, and found no obvious justification for the behavior you reported.

Then I consulted the source code. This is the line that determines that a tag followed by a space and the end-of-file has no right clearance, which means for a partial that it isn't standalone:

https://gitlab.com/jgonggrijp/wontache/-/blob/integration/mustache/mustache.coffee?ref_type=heads#L80

Here, slice[18] is the line-final whitespace, which crucially is not captured if there is no line end:

https://gitlab.com/jgonggrijp/wontache/-/blob/integration/mustache/mustache.coffee?ref_type=heads#L36-L37

Also crucially, end-of-file ($) does not count as a line end, only \n, \r\n or \r:

https://gitlab.com/jgonggrijp/wontache/-/blob/integration/mustache/mustache.coffee?ref_type=heads#L14

I think this is the culprit, and the behavior you reported is just an oversight. I will label this as a bug for now and investigate what happens if I add |$ to the newline regex.