Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support other preprocessors #533

Closed
phil294 opened this issue Sep 25, 2021 · 2 comments
Closed

Support other preprocessors #533

phil294 opened this issue Sep 25, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@phil294
Copy link

phil294 commented Sep 25, 2021

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

"preprocessors": {
  "coffee": {
    "lspPath": "/some/path"
  }
}

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!

@johnsoncodehk
Copy link
Member

Hi @phil294, this is the purpose of Plugin API.

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.

@phil294
Copy link
Author

phil294 commented Sep 25, 2021

ok I understand, thanks. Looking forward to this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants