Design Meeting Notes, 6/14/2023

[DanielRosenwasser]

Watch Factory Plugins

#54012

• What's the motivation for these?
• Editors and tools like VS Code have good file-watchers, often which can be shared between other language services.
  • This would fix a lot of TypeScript's file-watching reliability issues, avoid creating file-watchers within the TypeScript process itself, and would avoid exhausting OS resources for file-watching (usually on Linux).
• Main question in the last few meetings was "do we want this in compilerOptions or watchOptions?
  • Could be its own thing that's parallel to compilerOptions - but that makes the API surface area.
  • One thought would be to put it in the plugins array - which
• The biggest motivator is editing scenarios - is a plugin model overkill?
  • All the recent discourse on plugins has put pressure on
  • Can see a version that fits on TSServer but not on tsc.
• There are frequent issues filed on us based on file-watching - ask us to use a separate file-watcher, often provided by a daemon watcher process.
• Different options to solve the problem:
  • Write our own file watcher - we're doing this today but it's definitely not the best.
  • Let someone else plug in the file-watching.
  • Use someone else's file-watcher.
    • Peer dependency?
    • Vendoring?
• What does it mean to do custom file-watching only for TSServer?
  • Events via TSServer messages - LSP requires this anyway, "friendlier" for a lot of editors.
    • But probably more involved.
  • Current approach - roughly either via plugin model or something specific.
• Really two problems
  • Inaccurate file watcher
    • We believe a lot of the issues do come from the built-in watchers in Node.js - they may be due to platform-specific quirks, but it is tough.
  • Duplication of efforts in file-watching
    • Cannot solve this via quality.
• Revisiting the LSP-ish approach
  • It will be involved, but one day we may end up doing LSP anyway.
  • What would work best for web-based editors such as vscode.dev?
    • Editor ends up being the source of truth, ends up
• Why can't editors just use... tsserverlibrary.js instead of tsserver.js?
  • Can customize all of this to one's heart's content.
  • Well one has to copy/paste a bunch of code for the Node.js implementation that runs tsserver.js
• None of this works if you're using an editor that's not written in JS nor has its own file watcher.
  • Neither plugins nor using our API directly.
  • The LSP approach here has the upper hand.
• We are leaning away from the concept of watch plugins, and towards file watching events raised in TSServer sessions. We believe that it would address the most common issues that users hit, reduce resource consumption, and make it easier to eventually adopt LSP.

[DanielRosenwasser]

Language server watcher events implemented over in #54662.