tsconfig should support suffix `.jsonc`

[felix9]

Suggestion

🔍 Search Terms

• json
• jsonc
• tsconfig

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

tsconfig should support "extends": "pkg/foo.jsonc"

Currently that will try to read node_modules/pkg/foo.jsonc.json and fail

"extends": "./foo.jsonc" works. It only fails when trying to load a config using the node-resolution codepath.

📃 Motivating Example

Various dev tools complain about comments in .json files.

Many json config files allow comments, so most dev tools also understand a "json-with-comments" format, and the conventional file suffix for that is .jsonc.

Some dev tools special-case tsconfig.json as jsonc, and some tools also special-case variants like tsconfig*.json, but this is awkwardly inconsistent.

Supporting the suffix .jsonc will let people ignore the special-case irregularities and gravitate toward the generic file suffix.

Q: Why not some other json variant like .json5?

A: Other json variants try to fix other "json as configuration" problems in different ways, and none of them seem particularly dominant yet. jsonc is a conservative extension to json that has a lot of support, and it's also a subset of most of the other json variants.

And the tsconfig parser is already a jsonc parser, it doesn't need to change. It just needs support for the .jsonc suffix.

💻 Use Cases

[RyanCavanaugh]

You're already free to name this file whatever you like; tsc -p myconfig.jsonp and other project-related commands don't require any specific naming convention. tsconfig.json is the default name and would have to remain so for compatibility reasons. Adding another extension would introduce a ton of complexity because there'd have to be tie-breaking strategies (e.g. what if we found both in the same folder, what if we found tsconfig.jsonc in one folder and tsconfig in a parent, etc).

[felix9]

No, I know that -p can take any name. This is about "extends", it doesn't like the .jsonc suffix.

[RyanCavanaugh]

Thanks for clarifying, you're right

[bennycode]

@RyanCavanaugh this issue seems to be fixed because I just tested it with TypeScript 4.6.4 and it worked as expected 😀:

base.jsonc

{
  // A config file with a comment
  "compilerOptions": {
    "outDir": "myOutput",
  }
}

tsconfig.json

{
  "extends": "./base.jsonc",
  "compilerOptions": {
    "lib": ["es2017"],
    "module": "commonjs",
    "moduleResolution": "node",
    "rootDir": "src",
    "strict": true,
    "target": "es6"
  }
}

When running npx tsc I received transpiled output in the "myOutput" directory (as specified in "base.jsonc").

Further DX Improvements

It's great to see that you can feed the TypeScript compiler with JSON5 or JSONC files. I wish that tsc --init would also generate a tsconfig.jsonc (or tsconfig.json5) file but it actually generates a JSON file with comments which is invalid. This behaviour decreases the UX a bit as IDEs don't like it when you put comments into plain JSON:

WebStorm 2022.1.4

GitHub is also not a big fan of comments in JSON files and signals that in red:

GitHub File View