Rebuilt CLI watcher around new fswatch package - #4026

Pull request overview

This pull request rebuilds tsgo --watch around the new internal/fswatch package (OS filesystem events + debouncing) instead of the previous polling loop, while keeping internal/vfs/vfswatch as a baseline-snapshot change detector for tracked compiler inputs.

Changes:

• Replaces the CLI watch loop with an event-driven fswatch subscription (recursive + ignore filter) and coalesced DoCycle signaling.
• Simplifies internal/vfs/vfswatch by removing polling/timing/debounce machinery, leaving only snapshot + compare logic.
• Introduces a new multi-backend internal/fswatch implementation (fanotify/inotify/kqueue/FSEvents/ReadDirectoryChangesW), plus extensive tests and documentation.

Reviewed changes

Copilot reviewed 38 out of 38 changed files in this pull request and generated 3 comments.

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

The main issues here are

• Watch registrations are only derived from the starting tsconfig file—program files and failed lookups (together, everything in “seen files”) never get watched
• Those watch registrations are never updated—subscribe() is only called once on startup and sets up all the watches from the initial state. If the tsconfig changes (or the set of seen files, once that’s added into consideration), the watched locations need to be reevaluated.

Tests aren’t catching any of this because they call DoCycle manually—they check what happens after a rebuild gets triggered, but they never check what triggers you ask for. There are various ways you could handle this on the testing front; one would be to define an interface that matches the shape of fswatch.Watcher, allow that to be passed to execute.createWatcher, and use a mock implementation generated by moq in tests. That would let you inspect what watcher.WatchDirectory calls are made by subscribe.

Architecturally, I think I expected vfswatch to be completely deleted. With polling, you needed a complete snapshot of watched files and directories so you could detect whether anything changed between two cycles. But that responsibility has been completely removed—you now know your callback won’t happen unless something has changed that you requested to be notified about. Even if your watch registrations are overly broad, the fswatch library tells you what changed, so you can filter those events against the program, the tsconfig, and the set of seen files to make sure the event is relevant. So I don't think the snapshot of file system state is necessary anymore.

So to recap/restate, watch registrations should be part of the continuous cycle with building, not just a one-time setup, and after that, the decision of whether to build can get much simpler. It should look something like this:

flowchart TD
    A[New build] --> B[Discover current build dependencies]
    B --> C[Register / reconcile watches]
    C --> D[Wait for fswatch event]
    D --> E[Receive event]
    E --> F[Filter event against current build]
    F -->|Relevant change| A
    F -->|Irrelevant change| D
    F -->|Overflow / uncertain| A

Looks good to me... I think Jake Bailey (@jakebailey) was taking a look as well. Nice work!

I tried the node_modules remove and install and it works, while the editor funnily did not.

I think that the "should watch" logic is fine, copied from Strada. I think this is worth getting out there now.