Last active
June 6, 2024 22:45
-
-
Save dilame/32709f16e3f8d4d64b596f5b19d812e1 to your computer and use it in GitHub Desktop.
The most strict TypeScript tsconfig mode
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
{ | |
"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 | |
} | |
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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.