Closest to this is the --watch argument on the CLI (unified-args)

This is pretty interesting, but not doable easily. E.g., what is a “change”?

• Is that a change in the contents of a file?
• Or a different file path (file.path !== file.history[0])
• Should we start supporting stats, and track changes to mode, mtime, and the like?

I think this would be roughly related to GH-22 too.

Yes, it's a change in the original file when I use output: true

Why it should be related to a cache?

It doesn’t have to be, but my above three points are also what’s needed for caching. Albeit that “changed” files, as described above, relate to comparing a file before processing to after processing, whereas caching compares them between processes.

OK I got but for clarification my issue is only about to list which files are touched. Touch means as soon as I change the original content of the file (option: output).

Wait, are you talking about written files, instead of “changed” files?

No, I'm talking about updated files. List all written files is already supported but it doesn't help because it shows all found files based on the pattern.

Well, that’s hard. And then we need a definition of changed, and my proposal in my first comment is that I believe?

Yes. My proposal: changed means when source content != content (after processing). It doesn't matter if the content is saved to a different location when the content was changed.

First what we need to figure out is how to check if file.contents (string or buffer) equals a file on disk. I’m thinking node-stream-equal could work, if file.contents was made into a stream.
Any other thoughts?

Next steps would be to wrap that in a vfile-matches-file-on-disk utility (which obviously needs a better name). And then to filter the files here using that utility if a flag is set.