A glob pattern that controls which file events the watcher should report.
OptionalignoreCreateEvents: booleanIgnore when files have been created.
OptionalignoreChangeEvents: booleanIgnore when files have been changed.
OptionalignoreDeleteEvents: booleanIgnore when files have been deleted.
A new file system watcher instance. Must be disposed when no longer needed.
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.
Additional paths can be added for file watching by providing a RelativePattern with a
basepath to watch. If the path is a folder and thepatternis complex (e.g. contains**or path segments), it 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).Note that paths that do not exist in the file system will be monitored with a delay until created and then watched depending on the parameters provided. If a watched path is deleted, the watcher will suspend and not report any events until the path is created again.
If possible, keep the use of recursive watchers to a minimum because recursive file watching is quite resource intense.
Providing a
stringasglobPatternacts as convenience method for watching file events in all opened workspace folders. It cannot be used to add more folders for file watching, nor will it report any file events from folders that are not part of the opened workspace folders.Note that case-sensitivity of the globPattern parameter will depend on the file system where the watcher is running: on Windows and macOS the matching will be case-insensitive and on Linux it will be case-sensitive.
Optionally, flags to ignore certain kinds of events can be provided.
To stop listening to events the watcher must be disposed.
Note that file events from deleting a folder may not include events for the contained files. For example, when a folder is moved to the trash, only one event is reported because technically this is a rename/move operation and not a delete operation for each files within. On top of that, performance optimizations are in place to fold multiple events that all belong to the same parent operation (e.g. delete folder) into one event for that parent. As such, if you need to know about all deleted files, you have to watch with
**and deal with all file events yourself.Note that file events from recursive file watchers may be excluded based on user configuration. The setting
files.watcherExcludehelps to reduce the overhead of file events from folders that are known to produce many file changes at once (such as.gitfolders). 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.Note that symbolic links are not automatically followed for file watching unless the path to watch itself is a symbolic link.
Note that the file paths that are reported for having changed may have a different path casing compared to the actual casing on disk on case-insensitive platforms (typically macOS and Windows but not Linux). We allow a user to open a workspace folder with any desired path casing and try to preserve that. This means:
Examples
The basic anatomy of a file watcher is as follows:
Workspace file watching
If you only care about file events in a specific workspace folder:
If you want to monitor file events across all opened workspace folders:
Note: the array of workspace folders can be empty if no workspace is opened (empty window).
Out of workspace file watching
To watch a folder for changes to *.js files outside the workspace (non recursively), pass in a
Urito such a folder:And use a complex glob pattern to watch recursively:
Here is an example for watching the active editor for file changes: