Do we really need VS Code's file watchers? What do they do? How can they be disabled?

Question

VS Code is consuming my CPU resources intensively- mainly because of the file watcher. What does the file watcher do? In a react code, we already have hot-reload, do we really need this? How can we stop the file watcher completely?

I tried to add the "*" pattern in the files.watcherExclude to stop filewatcher, but I have no clue whether it's actually working or not.

Superiority

Why not ask this on their repository? – Dineric

On the pattern try adding ** but you can also find multiple issues on their repository that note various things to use for excludes based on the projects you deal with. An example – Dineric

This isn't quite an answer, but including some test data because I was curious: Both * and ** do not prevent file tree hints icons (ie yellow "M" for "modified"), when I focus the window again after editing the file externally. Also, the file's error count (ie red "9+") is only visible if I have the file open, regardless of this setting. I don't know what else this setting might affect. – Illegal

It looks like this rule DOES affect externally created files, eg touch foo.txt or npm install. See github.com/microsoft/vscode/issues/125886 for when they made VS Code watch node_modules by default, which you can disable with "**/node_modules/**": true, – Illegal

exclude "*" worked for me – Centner

Answer 1

FileWatchers in VS Code... watch files.

The VS Code API docs for the FileSystemWatcher interface states:

A file system watcher notifies about changes to files and folders on disk or from other FileSystemProviders.

Which should answer your question for what file watchers do.

---

The VS Code API docs for the createFileSystemWatcher workspace function are much elaborated:

Creates a file system watcher that is notified on file events (create, change, delete) depending on the parameters provided.

By default, all opened workspace folders will be watched for file changes recursively.

That's to be expected. How else would VS Code implement things like its Explorer view? (which updates itself when files and directories are added, removed, renamed, moved, etc.)

As for extensions that use this API to do things like providing Intellisense, how else would they know when you've created, edited, or deleted files in the programming/markup language they support, in order to hook that info into the rest of the software they use to provide their IntelliSense functionality?

---

You stated:

I tried to add the "*" pattern in the files.watcherExclude to stop filewatcher, but I have no clue whether it's actually working or not.

See this section of the createFileSystemWatcher docs:

Additional paths can be added for file watching by providing a RelativePattern with a base path to watch. If the pattern is complex (e.g. contains ** or path segments), the path will be watched recursively and otherwise will be watched non-recursively (i.e. only changes to the first level of the path will be reported).

---

VS Code and extensions that use the VS Code API can override your files.watcherExclude settings where they deem fit. From the createFileSystemWatcher docs:

Note that requests for recursive file watchers for a base path that is inside the opened workspace are ignored given all opened workspace folders are watched for file changes recursively by default. Non-recursive file watchers however are always supported, even inside the opened workspace because they allow to bypass the configured settings for excludes (files.watcherExclude). If you need to watch in a location that is typically excluded (for example node_modules or .git folder), then you can use a non-recursive watcher in the workspace for this purpose.

But the createFileSystemWatcher docs do warn its users to try to minimize usage:

If possible, keep the use of recursive watchers to a minimum because recursive file watching is quite resource intense.
[...]
Note that file events from recursive file watchers may be excluded based on user configuration. The setting files.watcherExclude helps to reduce the overhead of file events from folders that are known to produce many file changes at once (such as node_modules folders). As such, it is highly recommended to watch with simple patterns that do not require recursive watchers where the exclude settings are ignored and you have full control over the events.

So use the files.watcherExclude setting where you deem appropriate for your project, and trust VS Code and your extensions to do the right thing. If you really notice them being wasteful in some areas that generalize to all VS Code users and not just to you and your project, then you can file an issue ticket to VS Code or the extension presenting the case and evidence.

Now, if you're not just a user of an extension or VS Code, but you're developing VS Code or those extensions, the way to dispose of a FileSystemWatcher once it is no longer needed is to use its dispose method.

---

Extra tidbit: If you want to learn a bit about how file watchers are implemented, see this page in the VS Code wiki: https://github.com/microsoft/vscode/wiki/File-Watcher-Issues

Aphasic

Answer 2

I found that this problem is due to the directory level on which you open your file explorer. That is, when you open the file explorer, VS code auto-fills the directory to open with /home/yourUsername. If you accept this, then it only watches files in your home directory. However, if you change this to the root ( / ), then it will create file watches for everything in the entire OS, and devour your system resources.

Since you're not connecting remotely as root (right?), you can't access root-level directories through the file explorer anyway.

Vorster

It's pretty common to pair VSCode with Docker, where yes, you will be running as root (within the container anyway). – Herakleion

1) A container OS is significantly smaller. 2) You should be building your container from a build file not working inside of it, unless you're troubleshooting, in which case you could just use a terminal. 3) The number of files being watched is still the issue at hand. – Vorster