Sorry, I wasn't able to figure out what's all necessary to run tree-sitter parse locally, so I retrieved this from the playground instead and did my best to clean it up.
This should be treated as a normal string. I think this is simply due to an incorrect assumption that & will always lead to an HTML entity, which is not the case.
If there's a question of "why would you write this?", this comes from a dialect of TailwindCSS called Twind. Essentially this is a shorthand for utility classes that share the same base token (text(lg blue)) where the & is a self reference so that it's transformed into flex flex-col. I get that this particular use case is niche, but using an & in an attribute shouldn't be too out of the ordinary.
Likely related: https://github.com/tree-sitter/tree-sitter-javascript/commit/b16c69a70be907609950606e44ae266818ed8636
The following piece of code is valid but it is parsed incorrectly:
Here's a link to the TypeScript Playground showing that the snippet above is valid JavaScript or TypeScript:
https://www.typescriptlang.org/play?#code/MYewdgzgLgBApgDxgXhgCgJQoHwwDwAmAlgG4zAA2AhhBMgEQBmFiaAZDIyCBvTAPTYA3EA
The output of
tree-sitter parse
is the following:Sorry, I wasn't able to figure out what's all necessary to run
tree-sitter parse
locally, so I retrieved this from the playground instead and did my best to clean it up.This should be treated as a normal string. I think this is simply due to an incorrect assumption that
&
will always lead to an HTML entity, which is not the case.If there's a question of "why would you write this?", this comes from a dialect of TailwindCSS called Twind. Essentially this is a shorthand for utility classes that share the same base token (
text(lg blue)
) where the&
is a self reference so that it's transformed intoflex flex-col
. I get that this particular use case is niche, but using an&
in an attribute shouldn't be too out of the ordinary.