Support a file blacklist in tsserver configuration options

[weswigham]

My scenario is this: suppose I'm working in my editor, and I open a file which, by chance, crashes the language service. Repeatedly. (usually because of it's size or shape). Today, after the service crashes 5 times in short order, the service is disabled by the editor (which if it crashes on load, is what will occur). What I propose is this; if the service crashes after a file open request is issued, and we would shut down the service, instead we automatically add the file to a workspace-local tsserver blacklist config (probably in .vscode/settings.json) and reload the language service with the new option. The language service will then refuse to actually load the blacklisted file contents, instead reporting them as empty files/empty modules/empty json documents and potentially issue a warning-type error message in the diagnostics that certain files are blacklisted, which may affect the compilation.

cc @mjbvz do you think this'd be a good idea for a slightly more progressive degradation of experience when the language service has trouble with a file?

[mjbvz]

Interesting idea. Do you think that the file that we are passing in for updateOpen is always the root cause of these crashes, or could it another file in the project?

Another thing we could try: right now errors in updateOpen are fatal and trigger a TS server restart. However, at least some of these errors would likely not impact the user experience. If we restart the server multiple times, we could make the errors non-fatal instead. I worry though this this could leave some user's project intellisense in a really broken state (often it'd be better to have no intellisense and be notified of the error in such cases)

[weswigham]

Do you think that the file that we are passing in for updateOpen is always the root cause of these crashes, or could it another file in the project?

When a new file is opened, if we crash immediately, it's pretty much always due to an error while parsing, binding, or checking the new file; it's pretty rare that the crash is caused by an interaction between the new file and an older one; and even then, removing the new file would remove the interaction.

I worry though this this could leave some user's project intellisense in a really broken state (often it'd be better to have no intellisense and be notified of the error in such cases)

I think still reporting the "TSServer has crashed repeatedly" popup would be good in these cases (albeit with a slightly different message, like "TSServer has crashed repeatedly, and we've guessed that the inclusion of foo.js in your open files has trigged a crash. We've added it to an editor blacklist and disabled services for that file. You can reenable it by editing the list here."); it's just nice to still provide as much intellisense as we can, IMO. At least in my experience (working with alllll the edge cases), pretty much every time this happens when opening a new file, it's because the new file is some kind of big library/codegen thing with huge contents structured in a way we don't handle well, where I wanna look at the file in the editor, not actually intelligently edit it.

[weswigham]

Like, my primary peeve is that every time I open one of our regression tests for, eg #36248, since the editor LS still has the crash bug that PR fixes, it crashes repeatedly until I close the test file and restart the language service. The test file I'm looking at isn't part of any project I'm working on, it's just a loose file with a .ts extension that I've opened - ideally, it wouldn't impact the state of other, more functional projects.

[mjbvz]

I worry that an automatic blacklist could end up causing more confusion than it removes. It feels like a very specific solution to that your case

[weswigham]

Hmm, rather than per-file, could we disable services on a per-project basis, then? A crash in one project (like the workspace inferred project for loose files) shouldn't affect another (like the one produced by a tsconfig).