globby

Subj, does not ignore files. Test repro: test with node v24.16.0 globby 16.2.2

Regression in 16.2.2 (16.2.1 is fine). On Windows, any .gitignore rule that starts with a backslash escape crashes the glob when the file also contains a negation whose final segment is a glob. That includes the documented idioms for names starting with or (, ), not just junk rules: Backslash junk like also exists in real .gitignore files (microsoft/data-formulator line 416), which is how this was hit downstream: yamadashy/repomix#1765. Cause The new pruning logic compares each rule against negation names using the package; when the negation's final segment is a glob, passes the raw rule text to as if it were a path (, via → ). rewrites backslashes to slashes only in its Windows mode; its relative-path validation (active on every platform) then rejects the leading slash that results: → → throws. Mid-rule backslashes () are unaffected — only a leading escape produces a leading slash. This is also why the bug is Windows-only, and why CI didn't catch it: the windows-latest leg in main.yml is currently commented out. Failing tests Ready on , covering both the idiom and the real-world . The tests force 's Windows mode through its exposed test hook (), so they fail on every platform; on actual Windows the hook is a no-op.

Description We mount a large network share as a subfolder of a repository and list it in . markdownlint-cli2 uses globby with , so we expected the share to be skipped - instead every lint run crawls it in full over the network. The option starts by globbing for before any pattern is known, so the share is enumerated just to discover ignore files, before the rule that excludes it is ever applied. Two more things compound it: A single negation anywhere () disables forwarding to fast-glob's entirely, so the main glob also traverses every ignored directory and filters afterwards. Running from a subdirectory of a repository (e.g. a monorepo package) forwards nothing at all, because the patterns have been rebased onto the git root. Numbers 10k files in an ignored directory, instrumented, globby 16.2.1: git itself skips the directory instantly. On a network mount each of those reads is a round trip. Fix A fix is ready on : provably-safe prune patterns are handed to fast-glob (the predicate stays authoritative, so over-pruning is impossible by construction), and the ignore-file search prunes itself the same way. All three scenarios drop to 0 reads with byte-identical results, verified against across 35 conformance tests. We tried to open the PR but the repository currently limits interactions to collaborators; we will open it as soon as the limit lifts.