resolveFileSync returns no result when the discovered tsconfig has an unresolvable extends (tsgo still resolves)

[webpro]

Summary

When resolveFileSync (with tsconfig: 'auto', or an explicit tsconfig) discovers a tsconfig.json whose extends target cannot be resolved (e.g. a package that isn't installed), it returns TsconfigNotFound for every specifier from files under that config — including plain relative imports that don't depend on the tsconfig at all.

tsc / typescript-go instead treat an unresolvable extends as a non-fatal diagnostic (TS6053) and keep resolving modules, using the options that did parse.

This is separate from the recent extends-validity alignment (#1167, #1170): the extends here is correctly classified as not-found — the question is what module resolution does afterwards. It's also adjacent to #1011 (surfacing the loaded configs on error).

Reproduction

.
├── tsconfig.json
├── a.ts
├── b.ts
└── src/x.ts

// tsconfig.json — extends a package that is NOT installed
{
  "extends": "@acme/base/tsconfig.json",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": { "@app/*": ["./src/*"] }
  }
}

// a.ts
import { b } from './b';     // relative — does not depend on the tsconfig
import { x } from '@app/x';  // alias — uses local compilerOptions.paths

// b.ts
export const b = 1;
// src/x.ts
export const x = 1;

// repro.mjs   (npm i oxc-resolver)
import { ResolverFactory } from 'oxc-resolver';
const base = new URL('./a.ts', import.meta.url).pathname;
const opts = { extensions: ['.ts', '.tsx', '.js', '.d.ts'] };
const auto = new ResolverFactory({ tsconfig: 'auto', ...opts });
const plain = new ResolverFactory(opts);
for (const spec of ['./b', '@app/x']) {
  const r = auto.resolveFileSync(base, spec);
  console.log(`auto ${spec} ->`, r.path ?? r.error);
}
console.log('no tsconfig ./b ->', plain.resolveFileSync(base, './b').path);

Actual (oxc-resolver 11.20.0)

tsconfig:'auto'  ./b      -> ERROR: "Tsconfig not found @acme/base/tsconfig.json"
tsconfig:'auto'  @app/x   -> ERROR: "Tsconfig not found @acme/base/tsconfig.json"
no tsconfig      ./b      -> .../b.ts

The same TsconfigNotFound occurs with an explicit tsconfig: { configFile: '.../tsconfig.json' }, so it isn't 'auto'-specific.

Expected (matches tsc / typescript-go)

tsgo --traceResolution on the same project:

======== Module name './b' was successfully resolved to '.../b.ts'. ========
======== Module name '@app/x' was successfully resolved to '.../src/x.ts'. ========
tsconfig.json(2,14): error TS6053: File '@acme/base/tsconfig.json' not found.

Both the relative import and the path alias resolve (the latter via the local paths), and the unresolvable extends surfaces as a separate, non-fatal diagnostic — not as a failure of all resolution. At minimum, a relative import should never fail because of an unrelated tsconfig load error.

Impact

Any consumer using tsconfig: 'auto' over a workspace loses all resolution for files under a tsconfig that extends a package which isn't installed (common in monorepos, or before/while dependencies are installed). Downstream (knip) this currently requires a second, tsconfig-less fallback resolver to recover.

Environment

• oxc-resolver 11.20.0
• Node.js 24
• macOS (arm64)

[Boshen]

Is unresolvable extends actually useful in a real project?

I have to change the API shape if we want to return a valid result and a "error TS6053: File '@acme/base/tsconfig.json' not found." error at the same time.

[webpro]

Is unresolvable extends actually useful in a real project?

It's a project that tsc and tsgo accept: they emit TS6053 for the missing file and keep going, resolving and type-checking with the rest of the config. Today oxc-resolver aborts all resolution for any file under that config, which makes it stricter than tsc itself, and every tool built on it inherits that.

Concrete cases it breaks:

• Nuxt. The generated .nuxt/tsconfig*.json extends chain (the split app/server/node configs). On a fresh clone, in CI before nuxt prepare, or when one config in the chain isn't present yet, the paths tools rely on are right there in the config, but the missing extends takes the whole thing down.
• Monorepos extending a shared base by package name (@org/tsconfig/base.json, @tsconfig/node20) that isn't in that workspace's resolution scope: pnpm strict node_modules, the base is a devDep absent in a consumer, or before install. tsc emits TS6053 and continues.

In Knip the symptom is that alias imports under such a config become unresolved and their target files get flagged as unused, for a project tsc compiles cleanly.

I have to change the API shape if we want to return a valid result and a TS6053 error at the same time.

You don't need to return the error for this. Consumers like us only need resolution not to abort: treat an unresolvable extends as non-fatal, skip the missing base, keep the effective config from what resolved, and resolve normally. That keeps the current return shape.

From reading load_tsconfig, the extends targets are gathered with .collect::<Result<_, _>>()?, so a single get_extended_tsconfig_path returning TsconfigNotFound fails the whole load. Skipping an unresolvable extends target (while still erroring when the root config itself is missing, the test_extend_tsconfig_missing_file case) would match tsc and fix this with no API change.

Surfacing TS6053 alongside a successful result is a separate, nice-to-have, and could be additive or opt-in (a warnings list, or a flag) rather than a prerequisite for the resolution fix.