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 JS preprocessors #3200

Open
phil294 opened this issue May 19, 2023 · 5 comments
Open

Support other JS preprocessors #3200

phil294 opened this issue May 19, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@phil294
Copy link

phil294 commented May 19, 2023

Hi! This is a resurrection of #533 and a continuation of the conversation in #1687.

I am the author of CoffeeSense, the LSP/Extension for CoffeeScript. It would be great to support the usage of <script lang="coffee"> somehow.

I've read the blog post which contains this paragraph

If some of these language servers were based on Volar.js, we might have some way for them to decide to only activate one language server, and then share the features of the rest of the language servers to the activated one, so that in the end we would only need to run TypeScript Language Service in one language server instance instead of multiple language servers.

This is a good thought. It's a pretty ridiculous architecture to have every language server ship their own gigantic TS server... for example, CoffeeSense is actually a highly modified fork of Vetur, so it does exactly that right now.

However, I'm not sold on the approach that every supporting preprocessor needs to be completely reimplemented with volar technologies. So in 2021, I suggested

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 <script lang="coffee">, it simply functions as a proxy between client and a spun-up third party lsp instance at /some/path.

Is this something you would consider supporting now? Using LSPs as the interface between Volar and a preprocessor instead of me having to rewrite the entire extension.

Still, if you insist on the latter, some guidance would be much appreciated! But I probably don't quite have the capacities to do this, as I am glad I even got CoffeeSense to work properly in the first place. Also, there will usually also be normal .coffee files in a coffee-based Vue project. So in the worst case scenario, we'll have FOUR tsservers running simultaneously...

As you also asked for a sample repro: Here is a working demo of Vue+coffee (vue-cli/webpack based). Start with yarn serve. App.vue contains some comments.

CoffeeSense language server is also available as a standalone module (just like Vetur), see https://github.com/phil294/coffeesense/blob/master/server/README.md

Edit: I now did the reverse, so it's possible to get coffee support in .vue files by setting "files.associations": { "*.vue": "coffeescript" }. CoffeeSense has its own "parser" for sfcs consisting of a single small regex. Pretty shitty solution though as this disables any other vue tooling like this one. Why only does VSCode not allow for multiple languages in the same file -_-

@so1ve so1ve added the enhancement New feature or request label Jun 28, 2023
phil294 added a commit to phil294/coffeesense that referenced this issue Aug 7, 2023
if you change the type of your .vue files to coffeescript, this  extension will now extract the `<script lang="coffee"/>` section internally and provide autocomplete for it. Doesn't work with vetur/volar anymore then, though, because only one can be active at the same time. For current status on integrating both together, follow vuejs/language-tools#3200
@ofekd
Copy link

ofekd commented Apr 4, 2024

I am interested in this as well. Is it easier to do now that v2 is out?

@phil294
Copy link
Author

phil294 commented Apr 4, 2024

I have no idea. But since it doesn't seem there is much going on here, at least in the case of Vue.js, I have now simply added bare-bones Vue support into my CoffeeScript extension instead of the other way round and it works fine for JS-exclusive stuff

@ofekd
Copy link

ofekd commented Apr 5, 2024

thanks @phil294
@johnsoncodehk could you give a few hints/point in the right direction?

@so1ve
Copy link
Member

so1ve commented Apr 7, 2024

The current architecture doesn't allow us to do so. We heavily rely on TypeScript and its API to provide type-checking because we generate virtual TypeScript code from the template to make the syntax features work in templates.

@ofekd
Copy link

ofekd commented Apr 20, 2024

@so1ve Thank you for answering

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

3 participants