[Bug]: Symlinked files and folders never appear in file search or @ mentions#24547
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
In a project:
| 1 | mkdir -p src && echo 'export {}' > src/index.ts |
| 2 | ln -s src src-link |
| 3 | ln -s src/index.ts index-link.ts |
- In the composer, type
@link. - Open Files and search for
link.
Expected behavior
src-link and index-link.ts are offered, the same as any other file or folder in the project.
Actual behavior
Neither appears, because both places read the same server-side index, and the links are missing from it. I confirmed this at the server level, not by hand in the UI. Against a fixture with a folder link, a file link and a link nested under a real folder:
WorkspaceEntries.search({ query: "link" })returns["src/index.ts"]WorkspaceEntries.list({ cwd })(nodirectoryPath, the flat index) returns["pkg", "pkg/a", "pkg/a/deep.ts", "src", "src/index.ts"]and none of the links
Both come from the fff index. WorkspaceSearchIndex.ts creates it with FileFinder.create({ ... }) and does not pass followSymlinks, which @ff-labs/fff-node 0.11.0 defaults to false. In that mode, links are left out of the index entirely, links to files included, not just the folders behind directory links.
This is separate from #8408 and its PRs. #21920 (Files tree) and #8281 (path picker) fix the readdir filter in WorkspaceEntries.list and browse, and neither touches the index. Once #21920 lands, the Files tree shows a link but searching the tree for that link's name finds nothing.
The fix isn't obvious, which is why this is an issue and not a PR. fff documents followSymlinks as "Follow symlinks for directories", so turning it on presumably makes the scan descend into linked folders and index their contents under the link's path. That duplicates whole subtrees (one per pnpm package link in node_modules) and reaches whatever a link points at outside the workspace. Listing the link entries without descending into them would match what #21920 does for the tree, but I haven't checked whether fff can do that. Maintainers need to decide which behavior they want.
Impact
Minor bug or occasional failure
Version or commit
main at 3afb9b3 (also seen on a build from 2026-10-24)
Environment
Linux (Fedora), Node v24.13.1, @ff-labs/fff-node 0.11.0. Nothing about it is platform-specific.
Workaround
Type the path out by hand in the composer, or browse to the link in the Files tree once #21920 lands.