Allow tsconfig.yaml in addition to tsconfig.json
See original GitHub issueSearch Terms
yaml tsconfig format
Suggestion
I suggest allowing the tsconfig.json
file to be replaced with tsconfig.yaml
.
This would be implemented by simply converting the yaml to json and passing it to whatever method currently interprets the contents of tsconfig.json
.
Additionally, I would propose that the presence of both a tsconfig.json
and a tsconfig.yaml
file in the root of a project is an error.
Use Cases
Like #30400 (which I found originally), I’d like to add comments to my project config. Also, yaml is just a nicer format for something intended to be edited by a human.
I have created this simply because #30400 (which called for adding tsconfig.js
) was closed for reasons which do not apply to yaml. So I thought there should be an open issue. You can always close it for other reasons, right?
Examples
following the example in the handbook
% cat example.json
{
"compilerOptions": {
"module": "commonjs",
"noImplicitAny": true,
"removeComments": true,
"preserveConstEnums": true,
"sourceMap": true
},
"files": [
"core.ts",
"sys.ts",
"types.ts",
"scanner.ts",
"parser.ts",
"utilities.ts",
"binder.ts",
"checker.ts",
"emitter.ts",
"program.ts",
"commandLineParser.ts",
"tsc.ts",
"diagnosticInformationMap.generated.ts"
]
}
% cat example.yaml
compilerOptions:
module: commonjs
noImplicitAny: true
removeComments: true
preserveConstEnums: true
sourceMap: true
files:
- core.ts
- sys.ts
- types.ts
- scanner.ts
- parser.ts
- utilities.ts
- binder.ts
- checker.ts
- emitter.ts
- program.ts
- commandLineParser.ts
- tsc.ts
- diagnosticInformationMap.generated.ts
Checklist
I’M PRETTY SURE 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.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:110
- Comments:22 (3 by maintainers)
Top GitHub Comments
Additionally, addressing the question of “What shortcomings exist with current approaches?”
I did note that it was possible to add comments to the
tsconfig.json
. However, from a human-interface perspective, this is bad. People who know how JSON works know that it doesn’t generally support comments. So they won’t try to add comments to this file even if they want to. And people who don’t yet know how JSON works will see examples and try to put comments in theirpackage.json
files and find that it doesn’t work and be confused.Also, maintaining a JSON parser which supports comments is work which is probably better avoided (although I recognize that dropping support for comments in
tsconfig.json
may not be feasible). If you want to comment your config file, you can just use YAML. You don’t need to add one more unnamed, unstandardized way of having JSON-but-with-comments. I mean, now that you have you probably have to support it for some time, but pushing the existing userbase towards doing this by just using YAML would probably be a good thing.Please implement this.
JSON
is not a proper format, for configuration. Seeeslint
andprettier
. They both acceptyaml
formats. If Typescript accepted that, it would be a huge step forward. JSON, should never be the default configuration otpion. It is one more bad habit, that came fromnode
.