[Suggestion]: expose the remaining walker scope knobs (skipHidden, maxDepth, include) on InitOptions #992

Which frontend(s)?

Core or Rust crate

What problem are you trying to solve?

extraIgnore / disableGit / disableIgnoreFiles (#988) cover what gets excluded. The remaining indexing knobs are still decided by the engine, and three of them are already available in zlob (=1.8.0, which fff now pins) with no way for an embedder to reach them.

1. Hidden files are gated on "is this a git repo" — crates/fff-core/src/walk/zlob.rs:35-37:

let use_non_git_defaults = !is_git_repo && !ignore_options.disable_git;
if use_non_git_defaults {
    flags |= WalkFlags::SKIP_HIDDEN;
}

and the same rule in the ripgrep backend (walk/ripgrep.rs:26, .hidden(!is_git_repo)). So the same directory is indexed differently depending on whether a .git happens to exist: in a git repo every dot directory is indexed, outside one none are. An embedder cannot pick either behaviour.

Measured on a real 11,332-file repo (@ff-labs/fff-node@0.11.1-nightly.b3b8ced, darwin-arm64): 602 paths (5.3%) contain a dot component — .slim/ 318, .agents/ 61, .gitignore 49, .eslintrc.js 32, .prettierrc.js 18, .github/ 11. Which of those belong in a search index is a product decision (a VS Code extension wants .gitignore and .github/ out; an agent tool may well want .agents/ in), and right now it is made for us by whether the folder is a repo.

Related: #972 is the same split showing up between the scan and the watcher on non-git roots.

2. Depth limit — zlob::walk::WalkBuilder::max_depth(Option<usize>) (rust/src/walk.rs:226) is never called. Useful for very large mono-repos where only the top levels are worth indexing.

3. An inclusion glob — zlob::walk::WalkBuilder::include() + include_flags() (rust/src/walk.rs:172-193) restrict the walk to paths matching a pattern, and directories outside the pattern's literal prefix are pruned from traversal, not merely filtered. fff already has an internal scope: Option<&Path> (walk/zlob.rs:25, used by watcher/background_watcher.rs:841-855 to re-walk a subtree while keeping root-relative rules), but nothing embedder-facing.

This is not the same as #719/#80 (scan_inclusions, re-including ignored paths — negation) or #736 (picker-side directory search): here it is purely "index only this part of the tree".

Proposed solution

Extend FilePickerIgnoreOptions / the SDK's InitOptions with the three fields, defaulting to today's behaviour:

FileFinder.create({
  basePath: process.cwd(),
  extraIgnore: ['/generated/'],
  skipHidden: true,     // undefined = current rule (!is_git_repo only)
  maxDepth: 4,          // undefined = unlimited
  include: 'src/',      // undefined = whole tree
});

Why an embedder cares beyond taste: on Linux the watch set equals the index set (background_watcher.rs takes one NonRecursive watch per indexed directory, see the numbers in #530), so anything the walk does not prune is paid for twice — memory and fs.inotify.max_user_watches. include prunes traversal, so it buys the same thing as extraIgnore for the "only my code" case.

One caveat worth calling out: the ripgrep backend currently ignores FilePickerIgnoreOptions entirely (walk/ripgrep.rs:20 is _ignore_options), while zlob honours it. Keeping parity would need .hidden(true) and an OverrideBuilder scope there, but zlob is what release/npm builds ship.

Context: I maintain a VS Code extension on top of @ff-labs/fff-node (gaojunran/vscode-fff-search) that maps search.exclude/files.exclude into extraIgnore; these three would let it match VS Code's own indexing policy instead of approximating it. Happy to test a branch.