I have actually been working on it last week and came quite far. One thing that was a bit problematic was to adapt the watcher ID concept into LSP where there are no IDs. Curious to check how you've handled that.

After I'll check the changes out we'll have to decide which changes to go with based on what would be more efficient.

After cursory look I have some comments but I think it would be better to just go with my version of the code which is based on vscode's implementation more closely as that makes maintenance easier.

Some notes (but not sure you should spend time on those given what I said above):

• The setting whether to enable events should be passed through initializationOptions, not cli.
• Server explicitly doesn't support workspace folders (has no corresponding server capability) so there is no need to try to read those.
• Event manager doesn't do debouncing when notifying tsserver about events. The original vscode code does.
• The ts events related to watching are not currently handled so basically all the relevant code doesn't run
• There are issues with un-registering capabilities. It unregisters same capability multiple times rather than always the last one. Think there is a race condition in setting this.registration.
• The events are not matched properly against registered watchers. I had to do some quick hack fixes to get things running in the first place but looks like simple file change events are not reported to tsserver.
• There is a quite a lot of custom code for handling paths (normalizing, getting dirname, replacing (back)slashes). I wouldn't trust such code personally since there is a lot of corner cases that it might not handle. There are already established ways for doing that (URI class, os.path functions) that should generally work better. Assuming that it's even necessary to do all that.
• The most tricky part for getting this to work is matching file events from the client to tsserver watcher IDs and I'm not sure how well it works given the problems above.

I appreciate your efforts on getting registrations aggregated. Since tsserver is very granular in its events, I think your approach makes sense where you mainly just watch the root and match against tsserver watchers once the events are received. That said, I would still prefer to match vscode more closely in some parts.

Perhaps we can work together on this branch to get it working and finalized? That would be more efficient than going through PR comments. Alternatively I could work on my branch and potentially pick some stuff from you.

I appreciate your efforts on getting registrations aggregated. Since tsserver is very granular in its events, I think your approach makes sense where you mainly just watch the root and match against tsserver watchers once the events are received. That said, I would still prefer to match vscode more closely in some parts.

Perhaps we can work together on this branch to get it working and finalized? That would be more efficient than going through PR comments. Alternatively I could work on my branch and potentially pick some stuff from you.

Thanks so much for the detailed review and for taking the time to run and investigate my implementation. I really appreciate the explanations, a lot of these areas were things I didn’t fully understand when I started, and I learned a lot while working on this.
For me, this was mainly a learning experience and a way to understand how everything fits together, so feedback like this is really valuable.

I’m glad some of the ideas were useful. Since you already have a more complete implementation underway, I think it makes the most sense for you to continue with your version. Please feel free to take anything from my branch that helps.

No problem.

Lets work on this together then. I can push to the branch so it should be easy and we can discuss things as we go.

@rchl
Hi, thanks a lot for pushing those changes and continuing the work on this. I was a bit busy over the past couple of weeks, but I’m catching up now and will review them shortly.