Class string color scopes incorrect when v-model contains TS "as" cast

[qgates]

Example:

<textarea
  v-model="var as string"
  class="fld-module h-full resize-none">
...

Class string is assigned incorrect scopes meta.namespace.declaration.ts and source.ts.embedded.html.vue etc..

The order of attributes seems to make no difference. Workarounds:

• bracket the entire v-model expression eg. v-model="(var as string)"
• use angle bracket casting instead, eg. v-model="<string>var"

How it appears (using tomorrow night theme):

How it should appear:

[johnsoncodehk]

This problem similar to #112, it's embed language syntax issue, we can't fix, you need to use () to catch it.

[qgates]

@johnsoncodehk which upstream package is responsible for this issue?

[johnsoncodehk]

This: https://github.com/microsoft/TypeScript-TmLanguage

[mesqueeb]

@johnsoncodehk adding round parentheses fixes it. It might be interesting for volar to auto-add those inside templates.

Should I open a FR for this?

[johnsoncodehk]

@mesqueeb you can open a FR, but there is not necessarily a way to do it.

[douira]

What issue in https://github.com/microsoft/TypeScript-TmLanguage is the upstream issue for this? It doesn't make sense to have this closed without notifying the upstream repo to fix it.

[Mettbrot]

Marking any issue as duplicate of this one yet closing it without a proper path to get it fixed is kind of frustrating. How can we further track this issue, maybe over at microsoft/TypeScript-TmLanguage ?

[matthew-dean]

What issue in https://github.com/microsoft/TypeScript-TmLanguage is the upstream issue for this? It doesn't make sense to have this closed without notifying the upstream repo to fix it.

I think saying this is an upstream issue without pointing to the issue is a little dismissive / frustrating. I don't see, for example, how this can be purely an upstream issue when HTML languages don't have expressions like Vue has. It seems more likely (or at least possible?) that Vue is possibly identifying bound values as the wrong type of expression?

That is, if we assume:

• VSCode colors TypeScript correctly, and
• VSCode colors TSX correctly, and
• VSCode colors HTML correctly, then:
• How Vue's language tools are plugging into those services is probably incorrect. Even if Vue's coloring works 99% of the time doesn't mean that it's done correctly

If you aren't tracking an issue with Microsoft that has asked them for feedback, can you really prove otherwise? This feels like kicking the can down the road.

[johnsoncodehk]

@matthew-dean Even in .ts files, problems can occur when writing syntax equivalent to the original topic.

This is the code where we embed the ts syntax, you can try investigating:

language-tools/extensions/vscode/syntaxes/vue.tmLanguage.json

Line 1042 in ffa590a

"include": "source.ts"

I don't think upstream has a chance to fix it, it's more like a design limitation of the embedded language syntax highlight.