Setting to disable TS Service functionality

[gcazaciuc]

• VSCode Version:
  1.7.1
• OS Version:
  Ubuntu 16

Steps to Reproduce:
I and many people i'm working with use flow instead of typescript for typechecking and providing autocomplete/hover info.
The problem is that typescript autocomplete/hover suggestions also kick in which basically obscure the much more precise information that other extensions are able to provide in flow enabled code-bases.
I can imagine also other JS autocomplete providers being in the same situation.
I believe user should have a way to opt in/out for certain extensions to provide completions.
For the moment I'm looking for a way to disable the Typescript intellisense and keep only autocomplete suggestions from the flow extension.

Appreciate any suggestion.

[rozzzly]

An alternate suggestion: let one extension intercept the language service/providers of another extension/built-ins. If this were implemented correctly.... the following might be possible:

• An extension I make could provide altered, or superseded HoverProvider results instead of my results being appended behind that of tsserver's, yet maintain the same CompletionProvider, etc.
• Somebody else's extension for flow could completely block everything from tsserver and only flow's responces would be used.

For the case of flow, yes, one could change the Language Mode to some custom language mode, but then the implementer would need to provide something superior to what the tsserver team has developed... Allowing interception/interjection could make it possible to provide something extra without loosing all the awesome static analysis that tsservice provides.

[jrieken]

It seems like you want to disable typescript

[gcazaciuc]

Yes. I don't believe for a starter that we need any complicating mechanism: just a way to disable it just like any other extension. Then users have the freedom to chose whatever tooling/extensions make sense on their projects and also might save resourcesand make the editor even snappier if there are simpler extensions providing the functionality they need, as oppossed to spawning a full blown TSserver.

[jrieken]

@sandy081 Is that possible with the work you recently did in that area? Can we disable built-in extensions?

[dbaeumer]

The problem here is that flow files usually have a JS extension and that we treat them as JS files.

@gcazaciuc do the flow files have some header indication like // flow in them. If so an Flow extension should give these files the Language mode flow and then JS/TS will not react on them anymore.

@bpasero as that not how Flow used to work ?

[gcazaciuc]

Well, the problem is not as straightforward as that I believe:

1. Changing the language mode will impact other extensions that operate on JS files.
2. We will loose syntax coloring provided by external packages
3. It's not a medium term solution: I've seen discussions on the flow issue tracker in which Flow should process files based on flowconfig settings as opposed to header comment. In this case there will be no header indication anymore.
   Ideally it would be beneficial to be able to toggle on/off the TSServer with all the implications it has.
   Or have vscode recognize the //@flow heading and disable typescript analysis in those files.

[gcazaciuc]

i believe a non intrusive solution would be to expose an extension api to prevent or not the autocomplete results from other extensions similar to how Atom does it.

[waderyan]

@dbaeumer it seems reasonable to be able to disable all TS Service functionality.

@mjbvz @kieferrm what are your thoughts?

My thought is we expose a single setting to disable all TS Service functionality. Its like I am writing Python and I don't want the Python extension installed because I prefer to use VS Code as a simpler editor with less features.

[dbaeumer]

@waderyan yes that is reasonable but we shouldn't build another way for this. Instead I opt that we allow disabling build in extension like we allow disabling installed extensions. Opened: #17068

[waderyan]

Cool. Commented in that issue. Closing this issue as #17068 is a more holistic resolution.