fix: support symlinks without real paths with relative paths enabled #114
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #113
when investigating, i found out that the issue was caused by the following line:
fdir/src/api/walker.ts
Lines 120 to 121 in 5a0aab5
with relative paths on,
path
won't be an absolute path, and as such will be resolved in thestat
call as a path relative toprocess.cwd()
. this makes it throw anENOENT
error (unless the symlink happens to be located inprocess.cwd()
). i fixed this by changing the declaration to make it an absolute path instead.just fixing this line wasn't enough though, because the
resolvedPath
seems to always be absolute. to fix this, i did a substring transformation to a relative path (if the symlink is a file) if therelativePaths
option is enabled anduseRealPaths
isfalse
. the latter is because symlinks can point anywhere in the filesystem, so it should return an absolute path when that is the case.directory symlinks with real paths sadly still do not work with
relativePaths
on. my plan was to make it return those as absolute paths, but that is impossible as thejoinPath
function is already built as the relative path implementationsince symlinks with real paths and relative paths still behave inconsistently before and after this pr, i marked in the docs that resolving symlinks with real paths is only supported if the
resolveSymlinks
argument is set tofalse
also, while working on this i found (and fixed) another bug, it looks like file symlinks were never normalized, and as such could have the wrong path separator etc. fixed this by moving the
normalizePath
call before thestat.isDirectory()
check