dilame/tsconfig.json

If you know how to make it more strict – let me know in comments – i will update it.

One could just use strict: true to enable many of these by default, see https://www.typescriptlang.org/tsconfig#strict

These options should be added:

{
  "noImplicitOverride": true,
  "exactOptionalPropertyTypes": true
}

When strict: true is enabled, then these options can be removed:

{
  "alwaysStrict": true,
  "noImplicitAny": true,
  "noImplicitThis": true,
  "noImplicitUseStrict": false,
  "noStrictGenericChecks": false,
  "strictBindCallApply": true,
  "strictFunctionTypes": true,
  "strictNullChecks": true,
  "strictPropertyInitialization": true,
  "suppressExcessPropertyErrors": false,
  "suppressImplicitAnyIndexErrors": false,
  "useUnknownInCatchVariables": true
}

Thank you, @Zikoat, i added these options.

I personally don't like the idea behind strict: true flag. One of the main reasons is that it abstracts away certain details that I believe are essential for understanding and controlling the behavior of the code. Additionally, the specifics of what this flag entails can vary between TypeScript versions, which introduces an inconsistency that can be problematic for projects

I just found the official strictest tsconfig: https://github.com/tsconfig/bases/blob/main/bases/strictest.json. This file is a tsconfig base, which means that it is possible to extend the strictest base by adding it to your tsconfig.json:

npm i --save-dev @tsconfig/strictest

"extends": "@tsconfig/strictest/tsconfig.json"

See here for up-to-date info: https://github.com/tsconfig/bases#strictest-tsconfigjson

I just found the official strictest tsconfig

Based on their README: Owned and improved by the community, so it's not that official:) But it's an interesting project anyway

One of the main reasons is that it abstracts away certain details that I believe are essential for understanding and controlling the behavior of the code.

Yes, i agree. Having an explicit config is better in some cases when you are new to TS or when you don't know exactly what a flag does. Seeing all of the settings in your tsconfig is nice, and you won't have to check in the docs to see what is actually enabled.

the specifics of what this flag entails can vary between TypeScript versions, which introduces an inconsistency that can be problematic for projects

Yes, this means that different versions might give new error messages. Having a stable tsconfig might be better for large projects where you don't have the capacity to fix new errors, but if you are working on a smaller project and want to stay on the "latest, greatest and strictest" version, then extending the strictest base might be better.

Thanks a lot, next.js comes with default strict settings. Here are their default tsconfig.json settings:

{
  "compilerOptions": {
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "paths": {
      "@/*": ["./src/*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  "exclude": ["node_modules"],
}

Since "strict": true includes most of the settings you mentioned, I only had to add these:

{
  "noPropertyAccessFromIndexSignature": true,
  "noUncheckedIndexedAccess": true,
  "exactOptionalPropertyTypes": true,
  "noImplicitReturns": true,
  "noImplicitOverride": true,
  "forceConsistentCasingInFileNames": true,
  "noFallthroughCasesInSwitch": true,
  "noUnusedLocals": true,
  "noUnusedParameters": true,
  "allowUnreachableCode": false,
  "allowUnusedLabels": false
}