fix(deps): update dependency fdir to v6.4.2 #5889
Merged
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.
This PR contains the following updates:
6.4.0
->6.4.2
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
thecodrr/fdir (fdir)
v6.4.2
Compare Source
Fixes
maxDepth
was set to< 0
(#127)v6.4.1
Compare Source
Fixes
Recursive symlinks handling (#125)
Previously, fdir left it up to the OS to handle recursive symlinks. Unfortunately, this resulted in an infinite loop that'd either cause a crash or take too long to resolve (each OS has a different limit on resolving recursive symlinks). This has been fixed now in #126.
Recursive symlinks with
resolvePaths: true
When
resolvePaths
is set totrue
,fdir
does not crawl a directory it has already visited. To figure out whether we have visited a directory or not,fdir
maintains a list of all the directories it has visited. This might result in slightly higher memory usage than before.For a directory that looks like this:
fdir will return:
In short, you won't see duplicated paths in the output which is the expected behavior when working with file systems since paths are unique.
Recursive symlinks with
resolvePaths: false
When you set
resolvePaths
tofalse
, the behavior differs because now all symlinks become part of the path.For a directory that looks like this:
fdir will return:
To prevent recursion, all recursive symlinks are only resolved a single level deep making sure you never see something like
/dir/symlink/symlink/symlink/file
. This allows for glob patterns to work with recursive symlinks without creating a performance issue.Relative recursive symlinks
Relative recursive symlinks work exactly as above except the returned paths are relative to the root. Everything else is exactly the same.
Thanks to @SuperchupuDev for bringing this to my attention.
Configuration
📅 Schedule: Branch creation - "before 4am on Monday" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.