Fix issue with GTS transform with backtick comments#227
Conversation
🏎️ Benchmark Comparison
Full mitata output |
|
@copilot good, now find out where the fix should be, or if we need to improve the error coming from content_tag -- or if we need to open a failing test PR on content_tag |
Found this in our |
| let jsCode = code; | ||
| for (const tplInfo of [...result].reverse()) { | ||
| const content = tplInfo.contents.replace(/`/g, '\\`').replace(/\$/g, '\\$'); | ||
| const content = tplInfo.contents.replace(/[^\r\n]/g, ' '); |
There was a problem hiding this comment.
@copilot why is this the fix? what are we replacing (windows line endings)(?) with?
There was a problem hiding this comment.
The fix is in the lint-only placeholder path: we don't need template contents there, only stable offsets/lines for TS/ESLint. The replacement now masks every non-line-ending character in the template body with a space, while preserving \r and \n (including CRLF) unchanged. That prevents comment backticks/${...} from changing the JS template literal placeholder length or syntax. Clarified this in f864056.
transformForLintthrowsbad transformfor a valid GTS class template containing Glimmer comments with backtick-delimited text, even though the underlying parser accepts the template.transformForLinttest using the reported template shape.