tsserver hangs in Yarn PnP projects — incorrect directory watcher due to unchecked indexOf returning -1

[sebaspf]

🔎 Search Terms

tsserver hang, Yarn PnP, isInNodeModules, nodeModulesPathPart, watchNodeModulesForPackageJsonChanges, createModuleSpecifierCache, VS Code freeze on save

🕗 Version & Regression Information

Confirmed on TypeScript 5.8.3 and 6.0.2 (latest). This affects TypeScript versions within a Yarn PnP Project.

⏯ Playground Link

N/A — requires a Yarn PnP project and VS Code.

💻 Code

There are two instances of the same class of bug — unchecked indexOf/lastIndexOf returning -1 when a path doesn't contain the literal string /node_modules/, which is always the case in Yarn PnP projects.

Bug 1: src/server/moduleSpecifierCache.ts — createModuleSpecifierCache → set()

https://github.com/microsoft/TypeScript/blob/5f435057/src/server/moduleSpecifierCache.ts#L43

 if (p.isInNodeModules) {
     // No trailing slash
     const nodeModulesPath = p.path.substring(0, p.path.indexOf(nodeModulesPathPart) + nodeModulesPathPart.length - 1);
     //                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     //                                          Returns -1 in Yarn PnP (no /node_modules/ in path)
     const key = host.toPath(nodeModulesPath);
     if (!containedNodeModulesWatchers?.has(key)) {
         (containedNodeModulesWatchers ||= new Map()).set(
             key,
             host.watchNodeModulesForPackageJsonChanges(nodeModulesPath), // ← watches wrong dir!
         );
     }
 }

In Yarn PnP, TypeScript's own PnP integration (in src/compiler/moduleSpecifiers.ts) correctly marks cross-package module paths with isInNodeModules = true even when the path doesn't literally contain /node_modules/ (packages live in
.yarn/cache/*.zip paths). However, this code then assumes the path must contain the literal string /node_modules/.

When indexOf returns -1, the arithmetic becomes:

 substring(0, -1 + "/node_modules/".length - 1)
 = substring(0, -1 + 14 - 1)
 = substring(0, 12)

For a project in for example /home/myHome/projects/myProject the substring(0, 12) produces /home/myHome/ which is a valid path. This is then passed to host.watchNodeModulesForPackageJsonChanges(), which calls
watchPackageJsonsInNodeModules() → createNodeModulesWatcher() → watchFactory.watchDirectory(), creating a recursive directory watcher on the user's entire home directory.

This causes tsserver to enumerate and process every file under $HOME, hanging VS Code's extension host for minutes or indefinitely.

Bug 2: src/compiler/moduleNameResolver.ts — readPackageJsonPeerDependencies()

 const nodeModules = packageDirectory.substring(
     0,
     packageDirectory.lastIndexOf("node_modules") + "node_modules".length
 ) + directorySeparator;

Same pattern: lastIndexOf returns -1, producing substring(0, 11) + / → first 12 chars of the path. Then getPackageJsonInfo(nodeModules + key, ...) tries to resolve peer dependencies under that incorrect directory.

🙁 Actual behavior

Saving any file in VS Code with a Yarn PnP workspace causes tsserver to set up a recursive file watcher on the user's home directory (or an arbitrary prefix of the path, depending on home directory length). The VS Code GUI freezes.

Yarn patches Typescript setting isInNodeModules = true; even though there is no string /node_modules/ in the path. The Yarn patch doesn't touch the downstream moduleSpecifierCache.ts which assumes isInNodeModules === true means the path contains the literal string /node_modules/. So indexOf at moduleSpecifierCache.ts:42 would never return -1 in an unpatched TypeScript — the bug is latent but unreachable without Yarn PnP.

Without this check the module path matches the firs 12 letters in the path, that in my case happens to be my home directory (e.g. /home/myHome/) making Typescript to watch all files in my $HOME.

🙂 Expected behavior

When indexOf(nodeModulesPathPart) returns -1, the watcher/resolution should be skipped entirely (the path has no node_modules directory to watch).

Suggested fix

Bug 1 — Guard against -1:

 if (p.isInNodeModules) {
     const nodeModulesIndex = p.path.indexOf(nodeModulesPathPart);
     if (nodeModulesIndex !== -1) {
         const nodeModulesPath = p.path.substring(0, nodeModulesIndex + nodeModulesPathPart.length - 1);
         const key = host.toPath(nodeModulesPath);
         if (!containedNodeModulesWatchers?.has(key)) {
             (containedNodeModulesWatchers ||= new Map()).set(
                 key,
                 host.watchNodeModulesForPackageJsonChanges(nodeModulesPath),
             );
         }
     }
 }

Bug 2 — Early return when node_modules not in path:

 const nodeModulesIdx = packageDirectory.lastIndexOf("node_modules");
 if (nodeModulesIdx === -1) return undefined;
 const nodeModules = packageDirectory.substring(0, nodeModulesIdx + "node_modules".length) + directorySeparator;

Additional information about the issue

Environment:

• TypeScript
  5.8.3 and 6.0.2
• Yarn
  4.x with PnP (nodeLinker: pnp)
• VS Code with Yarn PnP TypeScript SDK (@yarnpkg/sdks)
• Linux (home directory path length happens to match the incorrect substring result)

Workaround:
create a link in some other place pointing to the repo and start VS Code with the yarn PnP SDK and Typescript support from there

cd /tmp
ln -s /home/myHome/myProject
cd myProject
code .

[RyanCavanaugh]

🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

Similar Issues

Here are the most similar issues I found

• (70%) microsoft/typescript#45891: direct import of files from node_modules triggers errors in ts 4.4 if watch mode is enabled
• (67%) microsoft/typescript#59413: Web TS Server tries watching for files outside of project root
• (67%) microsoft/typescript#60989: tsserver seems to watch entire home directory
• (67%) microsoft/typescript#27405: Debug Failure. False expression at getDirectoryToWatchFailedLookupLocation in openExternalProjects (tsserver)
• (67%) microsoft/typescript#19077: Debug failure in `startCachingPerDirectoryResolution`
• (67%) microsoft/typescript#47373: TS Server fatal error: Debug Failure. False expression.
• (67%) microsoft/typescript#58342: Watch cannot handle large amount of file changes
• (67%) microsoft/typescript#40616: Copying .ts files and renaming them confuses TypeScript
• (66%) microsoft/typescript#32033: VSCode and intellisense are broken and unstable
• (66%) microsoft/typescript#21459: High cpu usage on 01/29 insiders build
• (66%) microsoft/typescript#19327: tsc --watch is inconsistently reporting node_modules files as being outside rootDir
• (66%) microsoft/typescript#55135: TSServer forgets module type declarations, when using project references
• (66%) microsoft/typescript#19170: Excessive DirectoryWatcher recursive logs and TypeScript server hang
• (66%) microsoft/typescript#22710: Watch mode doesn't correctly invalidate failed subdirectory lookup results
• (66%) microsoft/typescript#47496: TS Server fatal error: Debug Failure. False expression.

If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.

Possibly Working as Intended

It looks like this behavior might be intentional. Here's what a computer had to say about it.

isInNodeModules is intended to be true only when the file’s path actually contains the literal segment "/node_modules/". All code in the TypeScript repo assumes that invariant; therefore it is safe to call indexOf("/node_modules/") without checking for –1.

In an unmodified copy of TypeScript that invariant always holds, so the substring math never runs on –1 and no watcher is created on an unrelated directory. The problem appears only after Yarn’s PnP patch sets isInNodeModules = true for virtual paths that are not inside a real node_modules folder. Once that invariant is broken, the downstream TypeScript code behaves exactly as written and computes an incorrect path.

Because the incorrect value of isInNodeModules originates in third-party patches, the observed behavior is outside the guarantees of the unmodified TypeScript compiler and tsserver. From the perspective of upstream TypeScript, this code is functioning as designed.