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

[domdomegg]

@bennycode Unfortunately this issue is not fixed. This issue is about the problem that you cannot import a jsonc file from another package:

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.

[alexweej]

My 2c: Not normalizing the use of the filename tsconfig.jsonc is a bit of an unnecessary microhazard. Many TSConfigs are pure JSON, and given that they have the .json filename extension, it'd seem reasonable to expect to be able to parse one using e.g. JSON.parse(...), when implementing tooling. Only potentially much later do you notice the bug when, e.g., someone brings a TSConfig scaffolded with tsc --init, full of comments, and then have to waste time going back fixing this.

Are we at risk of eroding the simplicity of 'JSON' here, in the entire ecosystem, because of things like this? Maybe an overblown statement, but still... the answer is yes IMO :)