there's actually a bug here i think. you would've uncovered it if your test asserted anything

if you crawl / with a symlink, it seems sync will return the entry twice and withPromise (async) will return it once

this seems to be because we're checking the visited set of nodes once we resolve the symlink, to avoid visiting it twice. in sync mode, we can visit the symlink before the target file has been visited and so visited won't contain it. in async mode, we resolve the symlink after already visiting non-symlink nodes, so visited is already populated and we return early.

i suspect this is a bug and is because we do the visited check when resolving a symlink , but not when visiting the target file. so we end up adding both

edit going to open a standalone issue for this

there's actually a bug here i think. you would've uncovered it if your test asserted anything

if you crawl / with a symlink, it seems sync will return the entry twice and withPromise (async) will return it once

this seems to be because we're checking the visited set of nodes once we resolve the symlink, to avoid visiting it twice. in sync mode, we can visit the symlink before the target file has been visited and so visited won't contain it. in async mode, we resolve the symlink after already visiting non-symlink nodes, so visited is already populated and we return early.

i suspect this is a bug and is because we do the visited check when resolving a symlink , but not when visiting the target file. so we end up adding both

edit going to open a standalone issue for this

Hmm, do you have any steps to reproduce this? I checked locally, and with a minimally mocked filesystem, both async and sync return [ '/usr/lib/file-1', '/lib/file-1' ]. Similarly, when using the full mock, files.length is the same in both cases.

More details here: #138

looks like this made windows ci hang 🤔