insights about File Watchers
Answered
Hi, I have some question about how File Watchers behave in different situations:
- a some files are modified, the watcher is currently processing command of the first edited file, what does it do next?
I understand that every changed file is queued, and for each one of the command is run sequentially
my command is general (e.g. "compile /folder"), so it's not meant to be run for every watched file, does the behaviour above change in this case?
From what I understand no, if it's a long process it's still going to be ran for every file changed after the command was run, even if it's the same file of course.
-
root files: not sure of what type of static analysis is done to determine dependencies, what is supported? what isn't?
"To run the File Watcher only against root files, select the Track only root files checkbox."
All files are watched, but the command gets called on the root file instead, if the appropriate macros are used.
"Clear the checkbox to run the File Watcher against the file from which it is invoked and against all the files in which this file is recursively included within the specified scope."
The command is executed from the edited file upwards, for every file in the chain, for every file changed. Even if the command is general
- "Output paths to refresh [...] Based on these settings, WebStorm recognizes the files generated through compilation."
I've seen that with this info, the watcher is able to ignore the output and not go in a loop if the output matches the files watched. The option is called "refresh", so I've been using it to "refresh" (from the disk?) folders too, something like "build/", or "build/*.*"? or "build"? Are all ok? Are folders ok? I can't really tell if they are working or not
Please sign in to leave a comment.
Hi Lucide,
1. IDE supports file-independent File Watchers and behaves accordingly. Make sure that there are no file-specific macros in the File Watcher settings. I mean 'Arguments', 'Output paths to refresh' and 'Working directory' fields, they shouldn't contain macros like $FileDir$ or $FilePath$ or any other $FileXXX$. In this case IDE runs File Watcher only once for a bunch of changed files.
2. Root files detection works for some file types like SCSS, or JavaScript, and some others. It analyses imports chain. I guess you shouldn't care given the answer #1.
3. Absolute output folder path will work fine.
If you have more questions please paste a screenshot showing your File Watcher settings. If you don't want to make your screenshot public, feel free to contact WebStorm Support.
Thank for your reply,
That's a lot of smartness and implicit behaviour changes that we got here. Is this in the documentation?
So, the ide uses the presence of file-related macros as an indicator to decide the most appropriate way to launch the command. (file-based/once for all)
It sounds useful for sure, but you understand that makes it harder to deduce the logic the watcher is following, if you don't already know what is doing and with what input.
"I guess you shouldn't care given the answer #1" I do care! I'm trying to get a good understanding of how file watchers reason, to eliminate that degree of uncertainty I have every time I work with them.
"The command is executed from the edited file upwards, for every file in the chain, for every file changed." (quote from my first post, read above for more context) Assuming a file-based command, is that correct? It makes me wonder if there is also a way to ignore dependencies?
Is there also a "folder-based" mode too, for when you use folder-based macros? Something like "run once for every folder (from the bottom level up, perhaps)"
> That's a lot of smartness and implicit behaviour changes that we got here. Is this in the documentation?
We should add if it's not.
> I do care!
Sure, sorry. Docs say that a root file is a file that is not included (for example via import) in any other file within the specified scope. For example, you edit file B but file watcher will run for file A if A imports B (if Track only root files is enabled), or both for A and B (if Track only root files is disabled). The check box is enabled only for several file types, for which IDE is able to track inclusion (imports).
If the File Watcher doesn't have file-specific macros in configuration, this check box doesn't make any difference.
> It makes me wonder if there is also a way to ignore dependencies?
Could you clarify the question (unless already answered)?
> Is there also a "folder-based" mode too
There's no such mode. If you use any file-specific macro (even $FileDir$), File Watchers will run for each changed file (or for root files based on changed files if 'Track only root files' is enabled)
> The check box is enabled only for several file types, for which IDE is able to track inclusion (imports).
Ahh I see, nice
> Could you clarify the question (unless already answered)?
I mean that both modes take in account dependencies, one goes for the root file, the other follows the dependency chain. Let's say I have a command that's not correlated to dependencies, something like a formatter, that I want to run on the modified file only, whether it is "root" or not. Can I express that?
> Let's say I have a command that's not correlated to dependencies, something like a formatter, that I want to run on the modified file only, whether it is "root" or not. Can I express that?
Thanks, understood. I'm afraid this is not supported yet. Originally, File Watchers were designed for things like compilation / transpilation / code generation. But these days they are used for file-updating tasks (like formatting) more and more often. I think we should completely ignore dependencies in such cases. I think IDE could use 'Output paths to refresh" set to $FilePath$ as a marker of a File Watcher that does not care about dependencies. This request is tracked as https://youtrack.jetbrains.com/issue/WEB-39699. Feel free to vote there to get notifications.
Ok, fair enough. I think having clarified all these file watchers "hidden" properties will make for a much better experience, as now I know what can be done and what cannot beforehand, without coming here complaining after the project has started.
I'll bookmark this thread for future references until the documentation is updated.
Thank you!