Remove Need for File Extensions in TypeScript Language Definitions #26413
Conversation
Part of microsoft#25740 To support TS Server plugins for languages like angular, we will allow extensions to register new langauges for TypeScript to watch. The angular language for example would want ng-html files to also be uploaded to TypeScript for checking The current language definitions all define both a set of language modes they support and a set of file extensions. The file extension part is unnessiary and may be incorrect depending on how a user sets up their `file.associations` in the workspace. This change removes the extensions part so that we always make use of the language mode
|
@mjbvz actually I know that there was a reason why I added this but I can't remember why. I will ping if I can recall it. Sorry for not being more helpful. The change looks good to me coding wise. |
|
Thanks for taking a look @dbaeumer. My main concern with this change was performance since we now will be calling |
|
@mjbvz now a bell rings. openTextDocument might be bad :-) The reason is that openTextDocument sends and open event (if not open already) which sends the document over to the server. If the document is already open that this is a no op, but if not we might put pressure on the server for no benefit. Assume the server reports errors on file not open (which might come at some point with the builder) then we would open every file in the server that has errors although it is not visible in VS Code. |
**Bug** Typescript previously used file extensions to determine which files it handles or not. This was not great because it duplicates information and also fails to account for `file.associations`. For the upcoming work on TS server plugin work, I switched to use openTextDocument for this check instead. However Dirk pointed out that this brings its own problems: microsoft#26413 (comment) . I don't see any ways around this using the current api, and I also don't see how we can fix the `file.associations` issue using the old extensions based approach **Fix** Add a new `getLanguage` api to VSCode. This api returns the language normally associated with a resource (uri). It does not take into account any language mode that a user has explicitly changed or the first line based language detection (since the goal was to avoid opening the resource in the first place). It's not clear to me if the current implementation based on openTextDocument will actually cause any problems. This new API may help us avoid some perf issues but also is not perfect. Let me know if you have any thoughts on this
Part of #25740
To support TS Server plugins for languages like angular, we will allow extensions to register new langauges for TypeScript to watch. The angular language for example would want ng-html files to also be uploaded to TypeScript for checking
The current language definitions all define both a set of language modes they support and a set of file extensions. The file extension part is unnessiary and may be incorrect depending on how a user sets up their
file.associationsin the workspace.This change removes the extensions part so that we always make use of the language mode