Skip to content

fix(tsconfig): resolve extends-inherited include/exclude/files relative to the declaring config#1204

Open
webpro wants to merge 1 commit into
oxc-project:mainfrom
webpro:fix/extends-inherited-include-paths
Open

fix(tsconfig): resolve extends-inherited include/exclude/files relative to the declaring config#1204
webpro wants to merge 1 commit into
oxc-project:mainfrom
webpro:fix/extends-inherited-include-paths

Conversation

@webpro

@webpro webpro commented Jun 6, 2026

Copy link
Copy Markdown

Summary

include / exclude / files inherited via extends are resolved relative to the extending config's directory instead of the config that declared them. rootDirs is already normalized at parse time relative to its declaring config (src/tsconfig.rs), but include / exclude / files were normalized later in build() relative to the root config.

TypeScript resolves these relative to the file they originate in:

All relative paths found in the configuration file will be resolved relative to the configuration file they originated in.

https://www.typescriptlang.org/tsconfig/#extends

Why it matters

An inherited relative include such as ../src/** is resolved against the wrong directory, so claims_ownership_of returns false and tsconfig: 'auto' walks up to an ancestor tsconfig.json — silently dropping the inherited paths and rootDirs.

This is SvelteKit in a monorepo: the app's tsconfig.json has "extends": "./.svelte-kit/tsconfig.json" (which maps ./$types via rootDirs and $lib via paths), and the monorepo root tsconfig.json is the ancestor. tsc / typescript-go resolve it; oxc-resolver did not.

Reproduction (added as a fixture)

extends-root-dirs-with-ancestor/
  tsconfig.json            // { "files": [] }   -- any ancestor tsconfig
  pkg/
    tsconfig.json          // { "extends": "./gen/tsconfig.json" }
    gen/tsconfig.json      // { "compilerOptions": { "rootDirs": ["..", "./types"] },
                           //   "include": ["./types/**/*.ts", "../src/**/*.ts"] }
    gen/types/src/data.ts  // export type Data = number
    src/consumer.ts        // import type { Data } from './data'

tsgo --noEmit -p pkg/tsconfig.json resolves ./data (no TS2307). resolve_file("pkg/src/consumer.ts", "./data") with tsconfig: 'auto' returned NotFound before this change — because the inherited ../src/** was resolved relative to pkg/ instead of pkg/gen/, so pkg/tsconfig.json failed to claim pkg/src/consumer.ts and discovery fell through to the ancestor.

Fix

Normalize include / exclude / files at parse time relative to the config that declared them — mirroring how rootDirs is already handled. build() now only resolves the {configDir} template (plain relative paths are already absolute).

Test

extends_root_dirs_with_ancestor_tsconfig — fails before, passes after. The full tsconfig suite stays green.

Distinct from #1185 (unresolvable extendsTsconfigNotFound).

…ve to the declaring config

`include` / `exclude` / `files` inherited via `extends` were normalized relative
to the extending config's directory instead of the config that declared them
(`rootDirs` is already normalized at parse time relative to its declaring config).

So an inherited relative `include` such as `../src/**` resolved against the wrong
directory, `claims_ownership_of` returned false, and `tsconfig:'auto'` fell through
to an ancestor `tsconfig.json` — silently dropping the inherited `paths` and
`rootDirs`. This broke SvelteKit in a monorepo (app `extends
./.svelte-kit/tsconfig.json`, mapping `./$types` via `rootDirs`, with a monorepo
root `tsconfig.json` as the ancestor), which `tsc`/`tsgo` resolve.

Normalize `include`/`exclude`/`files` at parse time relative to the declaring
config, mirroring `rootDirs`. `build()` now only resolves the `{configDir}`
template.
@webpro webpro force-pushed the fix/extends-inherited-include-paths branch from 4408329 to 42ed0d3 Compare June 6, 2026 06:01
@webpro webpro marked this pull request as ready for review June 6, 2026 06:01
@Boshen Boshen self-assigned this Jun 6, 2026
@Boshen

Boshen commented Jun 6, 2026

Copy link
Copy Markdown
Member

@shulaoda can you help with review

@shulaoda

shulaoda commented Jun 6, 2026

Copy link
Copy Markdown
Contributor

@shulaoda can you help with review

Got it, leave it to me. I’ll take a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants