You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is much better.
Please note that, if you use Node's default fs instead of memfs, you will see the following output, which we could consider canonical:
There is still a small difference between fs and memfs. In Node's fs, the last change event is for the parent directory. In memfs, the last change event is for the file itself. From the point-of-view of the user, it just looks like a duplicate event. Maybe it's due to #116 ?
If I add any additional writeFileSync() calls, both fs and memfs raise duplicate change events for the file, so, they match perfectly there.
Thanks a lot for your consideration!
The text was updated successfully, but these errors were encountered:
You can reproduce the problem with the following test code:
You will see the following output:
There is no event raised for
new_file
.It looks like this is due to the following setTimeout() call, which sends critical watcher attachments to the back of the timer queue:
memfs/src/volume.ts
Line 2514 in d78d6b8
If I remove that setTimeout() wrapper, I see the following output:
This is much better.
Please note that, if you use Node's default
fs
instead ofmemfs
, you will see the following output, which we could consider canonical:There is still a small difference between
fs
andmemfs
. In Node'sfs
, the last change event is for the parent directory. Inmemfs
, the last change event is for the file itself. From the point-of-view of the user, it just looks like a duplicate event. Maybe it's due to #116 ?If I add any additional
writeFileSync()
calls, bothfs
andmemfs
raise duplicate change events for the file, so, they match perfectly there.Thanks a lot for your consideration!
The text was updated successfully, but these errors were encountered: