You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
External File Watchers with
--watchFactory
#54012
package.json
s, failed lookup locations, etc.--watchFactory
flag - bothtsc
andtsserver
.create()
watchFile()
watchDirectory()
--watchFactory
is command-line only. Cannot be injected fromtsconfig.json
.Program
.Unexpected Behavior in
extends
Clause With Two Inferred Rest Types#50993?
[...infer P extends A[], Blah, ...infer S extends A[]]
, we don't really support a leading and trailing rest with elements in the middle.`${string}FOO${string}`
where we stop at the first occurrence ofFOO
and then try to infer before and after.tsserverlibrary.js
vs.typescript.js
typescript-eslint/typescript-eslint#6575
Session
s do.tsserverlibrary.js
instead oftypescript.js
typescript.js
.typescript.js
typescript.js
intsserverlibrary.js
?The text was updated successfully, but these errors were encountered: