fix: respect tsconfig/jsconfig exclude patterns in file watcher

[aewing]

Fix: Respect tsconfig exclude patterns in file watcher

svelte-check --watch was watching all files in the workspace regardless of what the tsconfig said to include/exclude. This caused performance issues in large projects and unnecessary diagnostics for excluded files.

What we did

• Added getProjectConfig() to the language server to expose the already-parsed tsconfig
• Added getWatchDirectories() to extract which directories TypeScript thinks should be watched based on the tsconfig include/exclude patterns
• Updated the file watcher to only watch those directories instead of the entire workspace
• Made the watcher update its watched directories when the tsconfig changes (with a 1 second debounce)

How it works

TypeScript already parses the tsconfig and figures out which directories to watch via its wildcardDirectories property - this has all the include/exclude logic already applied. We just use that instead of watching everything.

When the tsconfig changes, we diff the old and new directory lists and use chokidar's add() and unwatch() methods to update what we're watching without recreating the watcher.

[jasonlyu123]

Thank you for the contribution, but this isn't the right approach. We already have tsconfig.json parsing logic in the language-server package. https://github.com/sveltejs/language-tools/blob/master/packages/language-server/src/plugins/typescript/service.ts. This file also has logic for watching directories in the include patterns that are outside the workspace root. It also watches the tsconfig.json, so you also don't need to watch svelte.config.js for changes that might change tsconfig.json.

Also, as I mentioned in #2797. I think the right approach is to watch only directories that match the include pattern. Not the other way around.

[aewing]

@jasonlyu123 I have cleaned this up.
Added a method to get the project config from the typescript service.
Added an async getWatchDirectories to the svelte-check service in language-server.
Saved the watcher as an object property of the DiagnosticsWatcher.
On init/project reload we traverse watched directories and watch/unwatch from a heuristic diff.

[jasonlyu123]

Thank you, I left some comments.

[aewing]

Thank you, I left some comments.

addressed feedback, thank you!

[jasonlyu123]

There is another problem with this change. This will no longer watch the files that are loaded through module resolution and under the workspace root, but not under the "include" pattern. Of course, the old behaviour isn't ideal either. It should also watch files that aren't under the workspace root.

Having thought about this more, I am wondering if we should add the parent directory of these files to the result of SvelteCheck.getWatchDirectories. But this would make the check a lot more frequent. Or maybe it should be done in a callback option. The service.ts or the snapshotManager calls the callback function when a new snapshot is created. @dummdidumm, what do you think?

[aewing]

There is another problem with this change. This will no longer watch the files that are loaded through module resolution and under the workspace root, but not under the "include" pattern. Of course, the old behaviour isn't ideal either. It should also watch files that aren't under the workspace root.

Having thought about this more, I am wondering if we should add the parent directory of these files to the result of SvelteCheck.getWatchDirectories. But this would make the check a lot more frequent. Or maybe it should be done in a callback option. The service.ts or the snapshotManager calls the callback function when a new snapshot is created. @dummdidumm, what do you think?

Thoughts on this solution?
8b53cb8

[jasonlyu123]

onSnapshotCreated paired with a directory feels weird. It would probably be better if it sent the filename or replaced onSnapshotCreated with a more specific name.

[jasonlyu123]

I didn't see the usage of recursive here. Did you forget to pass it to chokidar, by chance? Also, maybe the currentWatchedDirs should also keep the recursive information. This way, we can skip the directory watch if the directories were watched recursively.

[jasonlyu123]

Ah. Chokidar doesn't support specifying recursive here. I'm fine with it always being recursive. In this case, we don't need to keep the recursive info here. We just need to check if it's under a directory we already watched.

[jasonlyu123]

I think we don't need this. If a new file is added, either it got added because of a file-watcher or it's added because of module resolution. In both ways, the file watcher should already trigger scheduleDiagnostics.