You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Coming over from https://github.com/eslint/rewrite/pull/117/files#r1742735782: TypeScript's compilerOptions.strict"enables a wide range of type checking behavior that results in stronger guarantees of program correctness. Turning this on is equivalent to enabling all of the strict mode family options... You can then turn off individual strict mode family checks as needed." Enabling strict is generally a TypeScript best practice. It's generally considered a must-have whenever possible: i.e. except when a pre-existing project is too large to easily migrate.
The two most impactful strict options are:
noImplicitAny: tells TypeScript to produce type errors if it can't infer a parameter or variable from its default or initial values
strictNullChecks in particular is necessary for a lot of typescript-eslint rules to run properly: search the intentionally obnoxiously named allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing in typescript-eslint.io
I understand there maybe some reluctance to enable strict on this repo. I think there was a discussion prior to #117 but I can't find it on demand. Are there strong reasons not to enable strict here?
The text was updated successfully, but these errors were encountered:
My main concern is the amount of effort required to meet strict mode out of the gate. At least in my (somewhat limited) experience, I've ended up running into issues where dependencies don't have type definitions and then I'm forced to create them (levn for example) or needing to reconcile types between packages we don't control (i.e., @types/eslint).
As someone who has a very limited number of hours I can devote to ESLint, spending those hours fighting with types doesn't seem like the best use of my time. (Or the team's time, where they may also be limited.)
It seems like we get around 80% of the benefit of type checking without strict mode.
That said, I'm not against strict mode in theory, I'm much more worried about it in practice. But I suppose if someone wants to come along and clean up my sloppy TypeScript behind me, I wouldn't mind that. 😄
I'm basically in agreement with @nzakas. I'm not sure about the value of refactoring the code just to enable strict type checks. In the first place that would be an exercise in JSDoc syntax, although it's well possible that the strict checks would also reveal inconsistencies in the code.
But if we decide to write unit tests for our type definitions (and I think we should), then it would be good to enable the strict option for the type tests. That would ensure that the type definitions work well in projects that have strict type checks enabled.
Coming over from https://github.com/eslint/rewrite/pull/117/files#r1742735782: TypeScript's
compilerOptions.strict
"enables a wide range of type checking behavior that results in stronger guarantees of program correctness. Turning this on is equivalent to enabling all of the strict mode family options... You can then turn off individual strict mode family checks as needed." Enablingstrict
is generally a TypeScript best practice. It's generally considered a must-have whenever possible: i.e. except when a pre-existing project is too large to easily migrate.The two most impactful strict options are:
noImplicitAny
: tells TypeScript to produce type errors if it can't infer a parameter or variable from its default or initial valuesconst log = value => console.log(value.toUpperCase()); log(123);
produces a type error only withstrictNullChecks
strictNullChecks
: makesnull
andundefined
their own types, rather than implicitly allowed (the "billion dollar mistake")let value: string = null; console.log(value.toUpperCase());
produces a type error only withstrictNullChecks
strictNullChecks
in particular is necessary for a lot of typescript-eslint rules to run properly: search the intentionally obnoxiously namedallowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing
in typescript-eslint.ioI understand there maybe some reluctance to enable
strict
on this repo. I think there was a discussion prior to #117 but I can't find it on demand. Are there strong reasons not to enablestrict
here?The text was updated successfully, but these errors were encountered: