-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Provide more structured type information to editors via tsserver #46701
Comments
It sounds like you’re interested in building a language service plugin. I believe you can even bundle this into a VS Code extension, have that insert the TS plugin, and then communicate between the VS Code extension (the client) and the TS plugin (run by TS Server). I think this is how https://github.com/denoland/vscode_deno works. Does that answer your question? |
Thank you! I expect to hit a couple specific issues later based on that readme you linked, but this definitely sounds like the concept I'm looking for. I think this issue can probably be closed and I can open more specific issues that are easier to triage later if needed. I'm going to jot down a few bullets about how language server plugins interact with this issue- could you give this a quick scan and see if I've got an accurate mental picture?
|
Yes.
I believe language server plugins can be added without tsconfig listing it by sending a command to TS Server. I think this is how the Deno VS Code extension works.
Historically true, but this is now possible via #44291
🤷 I’m not super familiar with existing uses in the wild. |
Sadly it's not true yet. |
This is somewhere between a suggestion and a question (and a blog post based on word count) that also touches on VS Code / LSP, so I didn't know where to put it. Feel free to point me elsewhere.
There are a few type related editor features I'm interested in attempting to implement, but they feel like relatively "core" or tightly integrated features. The most closely related projects I'm aware of have a few shared limitations that I'd also like to sidestep if possible. What I'm hoping to get out of this wall of text is a sense of whether these feel like "core" features I shouldn't be attempting without input from maintainers, whether there's a definitive "best approach" for tackling these types of features, and confirmation that these aren't already existing concepts. I think at least some of the changes would land in TypeScript and VS Code, which is why I'm dropping this here first. If this is the right spot for this conversation, I imagine we'll also want to tag
@mjbvz
into the conversation. I've done a fair amount of reading around the TypeScript repo over time if that makes it easier to explain anything.A few things I'm interested in playing with:
any
in the editor. Similar to the concept of code coverage and technically possible today by abusing@typescript/eslint
and making a custom rule to forbid the any type. Ideally I was hoping to make something visually more subtle that talks to the tsserver instance that's already driving TS support in the editor instead of having a parallel TS process. I'm less interested in code coverage as a build time check, and more interested in making it obvious whenany
is unintentionally bleeding somewhere. In my experience new TS devs don't have good intuition for when a single explicitany
will infect other types, and experienced TS devs still occasionally gloss over a type problem on accident by creating references to any in non-obvious ways. I suppose this is also closely related to semantic highlighting.@ts-ignore-error
or@ts-expect-error
by hovering/selecting them in the editor. This might be super easy or super difficult depending on how that suppression is implemented. I haven't dug around in that part of the code much.Shared limitations:
very vaguely related issue about code coverage: #36802
The text was updated successfully, but these errors were encountered: