Open felix9 opened 3 years ago
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).
No, I know that -p
can take any name. This is about "extends", it doesn't like the .jsonc
suffix.
Thanks for clarifying, you're right
@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").
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
@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.
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 :)
Suggestion
🔍 Search Terms
✅ Viability Checklist
My suggestion meets these guidelines:
⭐ 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
asjsonc
, and some tools also special-case variants liketsconfig*.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