Suggestion: an option to make --showConfig more verbose

[Asha20]

Search Terms

showConfig, verbose, verbosity

Suggestion

Currently, the --showConfig option will only print the compiler options that are provided by the given tsconfig.json.

The suggestion is to introduce another command line option to use together with --showConfig, for example --verbose, that would additionally print out the default values of all of the missing compiler options.

Use Cases

This new option hopes to make debugging configuration files easier by explicitly displaying the value of every compiler option.

Examples

Given the following folder structure:

.
├── main.ts
└── tsconfig.json

And the following tsconfig.json:

{
  "compilerOptions": {
    "target": "es5"
  },
  "include": ["**/*.ts"]
}

Running the command tsc --showConfig produces:

{
    "compilerOptions": {
        "target": "es5"
    },
    "files": [
        "./main.ts"
    ],
    "include": [
        "**/*.ts"
    ]
}

Here's an example output of tsc --showConfig --verbose. It was derived in the following way:

1. Use the Typescript Handbook's table of compiler options and their defaults as a reference.
2. Exclude deprecated options (out, reactNamespace, and skipDefaultLibCheck)
3. Also exclude any options that are missing a default value in the table, since JSON doesn't have a notion of undefined.

{
    "compilerOptions": {
        "allowJs": false,
        "allowSyntheticDefaultImports": false,
        "allowUmdGlobalAccess": false,
        "allowUnreachableCode": false,
        "allowUnusedLabels": false,
        "alwaysStrict": false,
        "build": false,
        "charset": "utf8",
        "checkJs": false,
        "composite": true,
        "declaration": false,
        "declarationMap": false,
        "diagnostics": false,
        "disableSizeLimit": false,
        "downlevelIteration": false,
        "emitBOM": false,
        "emitDeclarationOnly": false,
        "emitDecoratorMetadata": false,
        "esModuleInterop": false,
        "experimentalDecorators": false,
        "extendedDiagnostics": false,
        "forceConsistentCasingInFileNames": false,
        "importHelpers": false,
        "incremental": false,
        "inlineSourceMap": false,
        "inlineSources": false,
        "isolatedModules": false,
        "jsx": "preserve",
        "jsxFactory": "React.createElement",
        "keyofStringsOnly": false,
        "listEmittedFiles": false,
        "listFiles": false,
        "locale": "en", // [2]
        "module": "commonjs",
        "moduleResolution": "classic",
        "newLine": "lf", // [2]
        "noEmit": false,
        "noEmitHelpers": false,
        "noEmitOnError": false,
        "noErrorTruncation": false,
        "noFallthroughCasesInSwitch": false,
        "noImplicitAny": false,
        "noImplicitReturns": false,
        "noImplicitThis": false,
        "noImplicitUseStrict": false,
        "noLib": false,
        "noResolve": false,
        "noStrictGenericChecks": false,
        "noUnusedLocals": false,
        "noUnusedParameters": false,
        "preserveConstEnums": false,
        "preserveSymlinks": false,
        "preserveWatchOutput": false,
        "pretty": true, // [1]
        "removeComments": false,
        "resolveJsonModule": false,
        "rootDir": "(computed from the list of input files)", // [3]
        "showConfig": false,
        "skipLibCheck": false,
        "sourceMap": false,
        "strict": false,
        "strictBindCallApply": false,
        "strictFunctionTypes": false,
        "strictPropertyInitialization": false,
        "strictNullChecks": false,
        "suppressExcessPropertyErrors": false,
        "suppressImplicitAnyIndexErrors": false,
        "target": "es5",
        "traceResolution": false,
        "tsBuildInfoFile": ".tsbuildinfo"
    },
    "files": [
        "./main.ts"
    ],
    "include": [
        "**/*.ts"
    ]
}

^[1] The Handbook says pretty should be true unless piping or redirecting output to file, so the desired value here may be ambiguous?

^[2] locale and newLine are platform-specific.

^[3] rootDir would need to be calculated so it can be displayed.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[sandersn]

Maybe this is how showConfig should behave all the time?

[fatcerberus]

Yes. If I want to see only what's in the tsconfig, there's already cat. --showConfig would be more useful if it showed the effective config.

[barinbritva]

It also would be amazing if this verbose mode covers the lib option behavior. What I exactly mean:

Note: If --lib is not specified a default list of libraries are injected. The default libraries injected are:
► For --target ES5: DOM,ES5,ScriptHost
► For --target ES6: DOM,ES6,DOM.Iterable,ScriptHost

[WORMSS]

It also would be amazing if this verbose mode covers the lib option behavior. What I exactly mean:

Note: If --lib is not specified a default list of libraries are injected. The default libraries injected are:
► For --target ES5: DOM,ES5,ScriptHost
► For --target ES6: DOM,ES6,DOM.Iterable,ScriptHost

I came here for EXACTLY that... We added "an additional" lib to 1 project... and didn't realise it would REMOVE all the others and ONLY add the 1 lib... and we couldn't find an easy to consume definitive list that explains what all the libs we should be getting if we didn't override lib..
This would help us greatly..

Either that, or add an "appendLib".. because we only want to 'add' never 'replaceAll'

[orta]

Yeah, judging on the original intent (#15213) I think we can safely extend --showConfig.

I think we should detect for stdin on terminal, don't have it then act as today, maybe it's being used to pipe the tsconfig.

Otherwise, we use colors we show the resolved options in gray e.g:

I'd help get a PR for this merged 👍🏻

[barinbritva]

I don't know if that functionality should be a part of tsc. And I've create a prototype of tool which can compose full config. - tsconfig-helper. Basically it just uses data from official tsconfig reference.

Please let me know if somebody finds this tool helpful. If so it worths to develop it :)

[aaronadamsCA]

This would also help confirm when the docs are incorrect, which happens more often than you'd think.

[broofa]

Landed here because I'm wondering what, exactly, the default setting for typeRoots is.

The documentation for typeRoots implies the default is "typeRoots": ["./node_modules/@types"]. However actually setting that in tsconfig.json seems to break the built-in node type bindings (in VSCode).

[antitoxic]

Another argument for this is that other tools like eslint output exactly the full computed config when using their analogous --print-config. It would be very useful to debug configuration since when changing one tsconfig property it implicitly affects others.

[leegee]

How hard can this be, considering the configuration is loaded? Trying to debug a Vue 3 config that references/extends at least four other files. What a nightmare.

[oliver139]

Really need this for debugging

[pkerschbaum]

tsc --showConfig --project some-tsconfig.json is not just cat some-tsconfig.json as some imply in this thread; from looking into source code and trying some things out, it also

• resolves the inheritance (extends)
• and computes a couple of options if they divert from their default values

See the implementation of the command, which uses computedOptions to compute a couple of options not defined in the tsconfig file.

I guess to make the command output all effective compiler options is not easy, as code for that seems to be distributed in the codebase.
E.g. getting the effective typeRoots is here: https://github.com/microsoft/TypeScript/blob/caf1aee269d1660b4d2a8b555c2d602c97cb28d7/src/compiler/moduleNameResolver.ts/#L476-L492 and then used wherever needed.
Meaning as of today, tsc does not compute the full list of compiler options at some central place (which could just be printed via --showConfig).