Typescript: Allow tsconfig.yaml in addition to tsconfig.json

[dradetsky]

Search 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:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

[dradetsky]

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 their package.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.

[dradetsky]

@RyanCavanaugh is there a standard for "Received Enough Feedback" or is it just basically "Core devs feel that number of positive respondents is sufficient given the (expected) complexity of the change?"

I would note that @alexmiddeleer arguably counts as a positive respondent.

[EfstathiadisD]

Please implement this. JSON is not a proper format, for configuration. See eslint and prettier. They both accept yaml 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 from node.

[RyanCavanaugh]

is there a standard for "Received Enough Feedback" or is it just basically "Core devs feel that number of positive respondents is sufficient given the (expected) complexity of the change?"

There's no concrete standard. The number of positive respondents is one factor, but we're also considering the qualitative aspects of the verbatim comments -- e.g., are people completely blocked, are they inconvenienced, are they feeling a sense of technical friction, are they resorting to difficult workarounds, etc..