Design Meeting Notes, 5/3/2023

[DanielRosenwasser]

External File Watchers with --watchFactory

#54012

• Over the years, we've had several requests to just have TypeScript use chokidar, nsfw, parcel 3, etc. for file-watching.
• TypeScript has to do a lot of file-watching for project files, configuration files, package.jsons, failed lookup locations, etc.
• Idea: let tools consuming TypeScript to execute TypeScript with a --watchFactory flag - both tsc and tsserver.
• A watch factory needs 3 methods
  • create()
  • watchFile()
  • watchDirectory()
• Demo: a watch factory using parcel's watcher
• Also have a prototype of VS Code which registers a TSServer plugin which can operate over the current session instance.
  • Curious to understand full need for this.
• How do we scope what capabilities a plugin like this would need?
  • Have rejected features in the past based on security and performance concerns.
  • Hostile action is not as much of a risk - --watchFactory is command-line only. Cannot be injected from tsconfig.json.
  • Also, cannot patch the TypeScript API anymore as of TypeScript 5.0 thanks to the module migration, and cannot access certain core instances like Program.
• Who would use this?
  • Editors specifically - VS Code has anecdotally had a lot of success with Parcel 3's file watcher. They would like to be able to leverage for it for TSServer.
  • More than just that, they already have created all these file watchers for their own uses. So they want to share file-watchers across VS Code itself and TSServer.
    • Should result in less polling and less exhaustion of file watchers on certain operating systems (common on Linux).
• Would benefit from a diagram or something for this.
• If we ever did LSP which supports file watching over the wire, would that be a better approach?
• TSServer seems like the obvious use-case - would people really use this for tsc?
  • Yeah possibly.
  • Should we just ship this on npm?
    • Eh... it is easy enough to write, but we don't know the best thing for everyone.
• It would be really nice if this was in the core platform itself (e.g. Node.js, Deno, Bun).
• Conclusion: come back to the next meeting, decide on if we have consensus with this.

Unexpected Behavior in extends Clause With Two Inferred Rest Types

#50993?

• We fail to infer to a [...infer P extends A[], Blah, ...infer S extends A[]], we don't really support a leading and trailing rest with elements in the middle.
• We could add a case like this, act like we do for template string parsing for `${string}FOO${string}` where we stop at the first occurrence of FOO and then try to infer before and after.
  • Fishy - can have overlap between the middle and rest elements.
  • Not a problem exactly - matching is greedy for strings.
• We don't have a super-well-motivated scenario for this though.
• Though we do have some convoluted support for a specifically two rests with
• Conclusion: awaiting more feedback or just ask what the use-cases for this are.

tsserverlibrary.js vs. typescript.js

typescript-eslint/typescript-eslint#6575

• typescript-eslint only has the ability to use one project/program at a time
• In monorepos, they need to orchestrate all the different projects themselves
• That often doesn't work well because it has to reload many of the same files over and over.
  • The workaround is often to create a single uber-project just for typescript-eslint
  • RUH ROH
• What if typescript-eslint could just use all the infrastructure that TSServer uses to open individual projects at a time.
  • Basically using our "project service" to manage this - what our Sessions do.
• Works well, but now need to use tsserverlibrary.js instead of typescript.js
  • Sure but easy to still accidentally import from typescript.js.
  • Also, have other packages that still use typescript.js
• Can't we just re-export everything from typescript.js in tsserverlibrary.js?
  • Could do that - kind of a logistical nightmare for us.
• Might want to say long term that we want to move away from full fledged bundles for each of these.