tsconfig should support suffix `.jsonc`

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

Comienza rastreando el flujo de resolución de nodos utilizado para el valor de extends, centrándote en cómo se transforma pkg/foo.jsonc en una ruta. Verifica que las configuraciones .jsonc basadas en paquetes se resuelvan sin añadir .json, mientras que el comportamiento existente de ./foo.jsonc relativo permanezca sin cambios.