Skip to content

Instantly share code, notes, and snippets.

@dilame
Last active February 14, 2024 17:17
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dilame/32709f16e3f8d4d64b596f5b19d812e1 to your computer and use it in GitHub Desktop.
Save dilame/32709f16e3f8d4d64b596f5b19d812e1 to your computer and use it in GitHub Desktop.
The most strict TypeScript tsconfig mode
{
"compilerOptions": {
// Strict Checks
"alwaysStrict": true,
"noImplicitAny": true,
"strictNullChecks": true,
"useUnknownInCatchVariables": true,
"strictPropertyInitialization": true,
"strictFunctionTypes": true,
"noImplicitThis": true,
"strictBindCallApply": true,
"noPropertyAccessFromIndexSignature": true,
"noUncheckedIndexedAccess": true,
"exactOptionalPropertyTypes": true,
// Linter Checks
"noImplicitReturns": true,
"noImplicitOverride": true,
"forceConsistentCasingInFileNames": true,
// https://eslint.org/docs/rules/consistent-return ?
"noFallthroughCasesInSwitch": true,
// https://eslint.org/docs/rules/no-fallthrough
"noUnusedLocals": true,
// https://eslint.org/docs/rules/no-unused-vars
"noUnusedParameters": true,
// https://eslint.org/docs/rules/no-unused-vars#args
"allowUnreachableCode": false,
// https://eslint.org/docs/rules/no-unreachable ?
"allowUnusedLabels": false,
// https://eslint.org/docs/rules/no-unused-labels
// Base Strict Checks
"noImplicitUseStrict": false,
"suppressExcessPropertyErrors": false,
"suppressImplicitAnyIndexErrors": false,
"noStrictGenericChecks": false
}
}
@dilame
Copy link
Author

dilame commented May 18, 2022

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

@Maxim-Mazurok
Copy link

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

@Zikoat
Copy link

Zikoat commented Sep 29, 2023

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
}

@dilame
Copy link
Author

dilame commented Sep 29, 2023

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

@Zikoat
Copy link

Zikoat commented Sep 29, 2023

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

@dilame
Copy link
Author

dilame commented Sep 29, 2023

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

@Zikoat
Copy link

Zikoat commented Sep 29, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment