You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great if we also had support for less-popular preprocessors like e.g. SLM (HTML) or Elm, CoffeScript (JS).
Surely it is a lot of work natively integrating and supporting these, so I suggest a LSP interface for custom preprocessors. Say, a configuration object
And now, whenever Volar encounters a unsupported lang type as <something lang="coffee">, it simply functions as a proxy between client and a spun-up third party lsp instance at /some/path.
Of course, this falls short for special Vue syntax, like autocompletion for v-if inside a custom html preprocessor. But it's better than having no intellisense at all. In the case of Vue 3 composition api, things look bright anyway in comparison to Vue 2, where we needed magic under the hood to get TS integration.
Vetur's approach to preprocessors is to ignore them and instead wait for the specific language to consider Vue syntax individually, like in the case of ESLint. Volar seems to aim at integrating preprocessors into the codebase, if I understand the intent correctly. I think both approaches (if taken to the extreme) are wrong. Programming languages should arguably have higher precedence than frameworks, but language-to-framework is a a many-to-many relationship after all, just like tooling-to-ide is, so let's try and reuse existing servers whereever possible.
Congrats on becoming the recommended extension for Vue 3!
The text was updated successfully, but these errors were encountered:
For Elm / CoffeScript, it needs to be completely independent of TS processing, there is not much to talk about.
For template preprocessors, we need to implement a mapping protocol with template AST to support type flow analysis with v-if / v-for, and language support in interpolations.
Currently Volar does this internally for pug, but I planed migrate to plugin API in future.
It would be great if we also had support for less-popular preprocessors like e.g. SLM (HTML) or Elm, CoffeScript (JS).
Surely it is a lot of work natively integrating and supporting these, so I suggest a LSP interface for custom preprocessors. Say, a configuration object
And now, whenever Volar encounters a unsupported lang type as
<something lang="coffee">
, it simply functions as a proxy between client and a spun-up third party lsp instance at/some/path
.Of course, this falls short for special Vue syntax, like autocompletion for
v-if
inside a custom html preprocessor. But it's better than having no intellisense at all. In the case of Vue 3 composition api, things look bright anyway in comparison to Vue 2, where we needed magic under the hood to get TS integration.Vetur's approach to preprocessors is to ignore them and instead wait for the specific language to consider Vue syntax individually, like in the case of ESLint. Volar seems to aim at integrating preprocessors into the codebase, if I understand the intent correctly. I think both approaches (if taken to the extreme) are wrong. Programming languages should arguably have higher precedence than frameworks, but language-to-framework is a a many-to-many relationship after all, just like tooling-to-ide is, so let's try and reuse existing servers whereever possible.
Congrats on becoming the recommended extension for Vue 3!
The text was updated successfully, but these errors were encountered: