[Feature]: Fail loudly when extends/references in tsconfig can't be resolved, instead of silently using empty config

[bastitva0-blip]

🚀 Feature Request

In packages/playwright/src/transform/tsconfig-loader.ts, resolveConfigFile() has a fallback that retries unresolved extends/references paths against node_modules. The condition (referencedConfigFile.includes('/') && includes('.')) also matches ordinary relative paths, not just package specifiers. Since path.join collapses ../ segments, a typo'd relative reference like "../shared/tsconfig.base.json" hits this branch anyway, produces a second path that also doesn't exist, and innerLoadTsConfig's existsSync check then just returns an empty config — so a broken extends or references entry fails completely silently instead of erroring.

There's already a TODO on this exact line ("I don't see how this makes sense, delete in the next minor release"), which suggests this confused a previous maintainer too.

Feature ask: surface a clear error when a referenced or extended tsconfig path can't be resolved by either the relative or node_modules lookup, instead of silently defaulting to an empty config.

One related question worth settling first: playwright.dev/docs/test-typescript lists only allowJs, baseUrl, paths, and references as supported tsconfig options — extends isn't mentioned, but the code fully resolves extends chains. If extends support is intentional but undocumented, the fix should keep it working and just make failures loud. If it's legacy and unowned, maybe it should go away entirely along with this fallback. Happy to send a PR either way once that's clarified.

Example

Given a tests/tsconfig.json with:
"extends": "./tsconfig.bas.json" (typo :file doesn't exist)

Today: Playwright loads silently, the typo'd extends is ignored, and the paths/baseUrl the test author expected to inherit never get applied — with no warning, making it confusing to debug.

With this change: config loading would throw something like
Failed to resolve "extends" path "./tsconfig.bas.json" referenced from tests/tsconfig.json
at config-load time, pointing straight at the typo instead of leaving the misconfiguration silent.

Motivation

This bites people in a way that's hard to trace back to the actual cause. If you reorganize a monorepo, rename a shared tsconfig, or just typo a path in extends/references, Playwright doesn't error : it silently falls back to an empty config. The visible symptoms show up somewhere else entirely: path mappings stop resolving, baseUrl-relative imports break, or strict-mode settings you thought were inherited just aren't applied. None of that points back to "your tsconfig reference is broken," so people lose time debugging the symptom instead of the cause.

This is especially painful in CI, where there's no interactive session to poke around in — a silently-empty config just produces confusing downstream test failures with no actionable error message anywhere in the log.

Most config-loading systems (tsc itself included) treat an unresolvable extends as a hard error rather than a silent no-op, so failing loudly here would bring tsconfig-loader in line with the behavior people already expect from TypeScript tooling, and would turn a multi-hour debugging session into an error message that names the exact bad path on the first run.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at this.

Confirmed — your analysis is correct, and extends is intentional. A broken extends/references path is silently dropped: the resolved file doesn't exist, innerLoadTsConfig returns an empty config, and the failure surfaces somewhere unrelated (a module-resolution error) with nothing pointing at the bad tsconfig reference. That's a reasonable "fail loudly" request.

On the design question you raised: extends is intentional and is covered by tests (tests/playwright-test/resolver.spec.ts, "should support extends in tsconfig.json"), even though the docs page only lists allowJs/baseUrl/paths/references. So the fix should keep extends working and just make unresolvable references loud — not remove it.

What I reproduced

Against tip-of-tree (1.62.0-next). A typo'd extends means the inherited paths mapping is never applied, and the only error is the downstream Cannot find module — the broken tsconfig.bas.json reference is never named.

test('broken extends path is silently ignored', async ({ runInlineTest }) => {
  const result = await runInlineTest({
    'tsconfig.json': `{ "extends": "./tsconfig.bas.json" }`,            // typo
    'tsconfig.base.json': `{
      "compilerOptions": { "baseUrl": ".", "paths": { "util/*": ["./mapped/*"] } },
    }`,
    'a.test.ts': `
      const { foo } = require('util/file');
      import { test, expect } from '@playwright/test';
      test('test', () => { expect(foo).toBe('foo'); });
    `,
    'mapped/file.ts': `module.exports = { foo: 'foo' };`,
  });

  // Current behavior: the broken extends is swallowed.
  expect(result.exitCode).toBe(1);
  expect(result.output).toContain(`Cannot find module 'util/file'`);
  expect(result.output).not.toContain('tsconfig.bas.json');

  // Desired (#41543): fail at config-load time, e.g.
  // expect(result.output).toContain('Failed to resolve "extends" path "./tsconfig.bas.json"');
});

This passes today, pinning the silent behavior. The trigger is the early return in innerLoadTsConfig:

if (!fs.existsSync(configFilePath))
  return result; // empty config, no error

The node_modules fallback in resolveConfigFile (the one with the TODO) makes it worse for relative paths: ./tsconfig.bas.json matches includes('/') && includes('.'), so a second non-existent path is tried and also silently misses.

What I ran

• version: tip-of-tree (1.62.0-next), via npm run ttest
• scenario: typo'd relative extends; same code path applies to references
• not browser-specific — this is in the test runner's tsconfig loader, no browser involved

Full run: https://github.com/microsoft/playwright/actions/runs/28453178304