Description

When using pnpm as the package manager, unrs-resolver fails to resolve tsconfig files that are dependencies of other dependencies.

The resolver appears to search for dependencies only within the project's root node_modules. While this succeeds in npm or yarn due to their default hoisting behavior, it fails with pnpm in the default configuration because it uses an isolated directory structure where transitive dependencies are not moved to the root.

Reproduction

Reproduction Link: StackBlitz Example - run pnpm test

The Scenario

The failure occurs when a project uses a "chained" tsconfig dependency structure:

1. Project Root tsconfig.json ⮕ extends dependency-outer
2. dependency-outer tsconfig.json ⮕ extends dependency-nested

Directory Structure (pnpm isolated)

In a pnpm workspace, dependency-nested is not hoisted to the root. The file system looks like this:

my-project/
├── node_modules/
│   └── dependency-outer/
│       ├── package.json
│       ├── tsconfig.json  <-- (Tries to resolve 'dependency-nested')
│       └── node_modules/
│           └── dependency-nested/ <-- (Located here, NOT in root)
└── tsconfig.json

Expected Behavior

unrs-resolver should resolve dependency_nested by searching relative to the tsconfig.json that is importing it. It should follow the standard Node.js resolution algorithm (looking in the local node_modules of the parent package).

Actual Behavior

unrs-resolver only checks the root node_modules. Since dependency_nested is hidden within the dependency_outer hierarchy (due to pnpm's isolation), the resolver fails to find the file.

Workarounds

It's possible to work around this issue by utilizing pnpms publicHoisPattern setting and adding the dependency-nested there. This forces pnpm to move the dependency-nested to the root node_modules and everything works.

Environment

• Package Manager: pnpm (v9)
• pnpm Setting: nodeLinker: isolated (Default)