Unpaired apostrophe in JavaScript comments causes "Unexpected token '%'" error in template parsing

[polyaklaci]

Describe the bug When using an unpaired apostrophe (') inside JavaScript comments within an Eta template block, the template parsing fails with an "Unexpected token '%'" error. Paired apostrophes ('like this') work correctly, but single apostrophes used in contractions (it's, don't, can't) cause the parser to fail. The apostrophe appears to be treated as an opening string delimiter even when it's inside a comment. The documentation states that Eta "doesn't break with delimiters inside strings and comments", but this is not the case for unpaired apostrophes.

To Reproduce Steps to reproduce the behavior:

1. Create an Eta template with a JavaScript code block:

<%
  const foo = 'bar';
  // This comment with unpaired apostrophe: it's broken
  console.log(foo);
%>

2. Try to render/compile the template
3. Receive "Unexpected token '%'" error

Expected behavior The template should compile successfully, as apostrophes within JavaScript comments should be treated as part of the comment and ignored by the parser. According to the documentation, Eta should handle delimiters inside comments correctly.

Package & Environment Details

• Version: eta 3.5.0

Additional context

• Paired apostrophes in comments work fine: // This 'works' correctly
• Unpaired apostrophes cause the error: // This doesn't work
• The issue only occurs with unpaired apostrophes (common in English contractions)
• Other special characters in comments work fine
• The parser appears to treat the unpaired apostrophe as an opening string delimiter, waiting for a closing one
• This contradicts the documentation which states that Eta "parses strings and multi-line comments correctly"

Workaround Avoid using contractions with apostrophes in comments:

// Instead of: it's, don't, can't, won't
// Use: it is, do not, cannot, will not
// Or use paired apostrophes: 'it's' (though this changes the meaning)

[bgub]

Thanks for filing, @polyaklaci. I can't think of a performant way to fix this, so I will leave this open as a known issue for now.