tsc --showConfig: print the final tsconfig after extends and defaults

tsc --showConfig prints the configuration that tsc would actually use, as JSON, and exits without compiling. The output merges every extends level, applies command-line overrides, expands include/exclude globs into the concrete files list and adds options implied by others. It is the quickest way to answer "which target am I really using?" in a project with shared base configs.

Resolving extends and overrides

npm init -y >/dev/null
npm install --silent --no-audit --no-fund typescript@7.0.2 >/dev/null 2>&1
mkdir -p configs src
echo 'export const ok = true;' > src/index.ts
echo 'export const t = 1;' > src/index.test.ts
cat > configs/base.json <<'EOF'
{ "compilerOptions": { "strict": true, "target": "es2020", "module": "nodenext", "types": [] } }
EOF
cat > tsconfig.json <<'EOF'
{ "extends": "./configs/base.json", "compilerOptions": { "target": "es2022", "outDir": "dist", "rootDir": "src" }, "include": ["src"], "exclude": ["src/**/*.test.ts"] }
EOF
npx tsc --showConfig; echo
echo "== with --noEmit on the command line"
npx tsc --showConfig --noEmit | grep -E '"(noEmit|target)"'
ls dist 2>/dev/null || echo "no dist folder: nothing was compiled"

{
    "compilerOptions": {
        "module": "nodenext",
        "outDir": "./dist",
        "rootDir": "./src",
        "strict": true,
        "target": "es2022",
        "types": [],
        "moduleResolution": "nodenext",
        "moduleDetection": "force"
    },
    "files": [
        "./src/index.ts"
    ],
    "include": [
        "src"
    ],
    "exclude": [
        "src/**/*.test.ts"
    ]
}
== with --noEmit on the command line
        "noEmit": true,
        "target": "es2022",
no dist folder: nothing was compiled

The target from the project file (es2022) wins over the base (es2020), strict and module come from the base, moduleResolution and moduleDetection appear because module: nodenext implies them, and the test file is gone from files because of exclude. Command-line options such as --noEmit show up in the output too.

What the output contains

Common uses

tsc --showConfig > resolved-tsconfig.json         # snapshot for code review or a bug report
tsc -p tsconfig.build.json --showConfig           # check a non-default config
tsc --showConfig | grep -A3 '"paths"'             # verify path aliases after extends

• Monorepos: shared bases in @org/tsconfig packages make the effective strict or module settings hard to trace; --showConfig shows the result in one place.
• Migrations: after changing module, moduleResolution or target, confirm the merged value before chasing errors such as TS5108.
• "File not included" problems: if a file is missing from files, the error is in include/exclude, not in the code.

Pitfalls

• Relative paths in the output are relative to the config that was loaded. A path that looks wrong often comes from a base config whose outDir was resolved from its own folder; see tsc -p.
• --showConfig reports the config it found by the normal lookup (current folder, then parents). Run it from the folder you build in, or pass the config with -p.
• The output is the resolved config, not a valid replacement for the original: extends is gone and globs are expanded, so do not commit it as your new tsconfig.json.

FAQ