Symlinked types not being watched for updates

[Eldritch-Oliver]

So, I'll start this off with not being sure whether or not the language server is meant to do this or not (hence why I didn't use the bug nor feature request template), but I've narrowed it down to this.

---

In one of my projects, I have the following directory structure:

proj_root:
 |−− server
 |  |−− src
 |     |−− types (symlink pointing to /common/types )
 |     |−− <rest of my Typescript server code here>
 |−− web
 |  |−− src
 |     |−− types (symlink pointing to /common/types )
 |     |−− <rest of my svelte code here>
 |−− common
    |−− types
       |−− Status.ts (includes a Status enum declared in it)

---

And I'm trying to make it so that I can use the same types between both the server and web sources so I don't need to write the same types multiple times if both of the things need it.

Currently, when I add an enum member into /common/types/Status.ts, I have to restart the Svelte language server in order for intellisense to recognize the new enum member.

Is there any way to get the language server auto-updating the types when I add/edit types within /common/types? I've dug around for settings or people with similar situations and couldn't find any, so any and all help is greatly appreciated.

---

System Information: OS: Ubuntu 20.04 LTS (Linux x64 5.11.0-43-generic) IDE: Visual Studio Code 1.63.2 Extension: Svelte for VS Code Typescript Version: 4.3.4 Node Version: v14.17.0

If there's any additional information you'd like me to provide let me know and I'll happily provide it.

[dummdidumm]

I didn't validate this, but my assumption is the following:

By default, we are not noticed of changes inside TypeScript files. We added a listener so that we are notified here on the client side of the extension. This manual workaround likely is the culprit:

• Either we are not notified of file changes at this position, which would be unfortunate and I don't know how we could fix that
• Or we are notified, but the path is the original path and there's no logic that this also changes a symlinked file. Maybe there are node utilities to get the links to a file (I know you can find out the original file from a symlinked file, but I don't know the other way around)

While we're at it: I'm wondering whether or not we could change the watch logic and move it from the client to the server. This would likely mean reimplementing some of the stuff the TS Server does: Setting up watchers for each TS file we find and notifying of the changes. We then would also need to implement some kind of diffing algorithm so we get the same nice "only this part changed" behavior the VS Code client already gives us. We also need to be carful about the performance implications of this. Having written all that, I'm no longer sure if it would be a good idea 😄 @jasonlyu123 thoughts?

[jasonlyu123]

Both seem to be possible. The first case might be that the original file is not in the workspace. But in this case, we'll have to create a file watcher to detect it. The second one should be a little bit easier to handle.

What I think we can handle this is to create a map to track the file path to its real path(Map<string, string>) or a map for the real path to all the symlinked file path(Map<string, string[]>). So when the real path is updated we can also apply it to the symlinked files.

About moving the watch logic, the benefit I could think of this is that the files not included in the file watcher of vscode could be tracked. We'll still have to track the files through the onDidChangeTsOrJsFile command as those are stored in the client's memory.

[dummdidumm]

Oh right, unless someone saves we won't be notified, which makes rewriting this part even less appealing.

I like the idea of having a map (or two maps) for tracking the dependencies, I'm still not sure how we would build them up though. Maybe open opening of a file we check if it's a symlinked file, and if yes, add that info to that map. That way, if an update from a symlinked file appears later on we can propagate it to the other files/the original file.