Provide warnings/errors when putting tsconfig compilerOptions in the root of the tsconfig.json

[orta]

Suggestion

🔍 Search Terms

TSConfig root fields errors

✅ Viability Checklist

• 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

{
    "target": "es2017",
    "module": "commonjs",
    "lib": [
      "esnext",
      "es2015",
      "es2016",
      "es2017"
    ] 
}

Should give some sort of feedback that you really want:

{
  "compilerOptions": {
    "target": "es2017",
    "module": "commonjs",
    "lib": [
      "esnext",
      "es2015",
      "es2016",
      "es2017"
    ] 
  }
}

📃 Motivating Example

I can't think of a reason why you might want to have these keys in the root of your tsconfig, open to ideas about why you might.

💻 Use Cases

New folks who accidentally set up the tsconfig wrong

[RyanCavanaugh]

Other tools are allowed to use the top-level keys here, and do, so there's some danger of compat problems if in the future we add a compiler setting with the same name as a tool's setting

[orta]

This came up again, could it be that if we detect both target and module (as I would imagine they are the most popular options) in the root then we raise an error. It leaves the space open for a tools called both 'target' and 'module' to exist I the future, but for them both to not be in the tsconfig.

We should raise for target or module in the root as having a string value that is one of our accepted values. I think that'd be future proof and catch most mistakes.