-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repo: Enable TypeScript's "strict" mode #118
Comments
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 ( 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 curious what others think. |
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 |
@mdjermanovic still waiting for your feedback here. |
I agree to not enable strict mode. Seems that would require a lot of effort for the present and future code, and as said we already get a lot of the benefit of type checking without strict mode. |
If you don't have types that's okay - you can declare them locally if you want to strictly type everything (which is the general recommendation and best practice, of course). But ultimately your local type declaration could simply be "add I would very, very strongly urge you to at least turn on function test(arg: string | null) {
// NO ERROR?!?!?
arg.length
} playground with
|
@bradzacher thanks for the details on these. It seems like these options would be useful:
I'm not sure I understand this -- why would you assume |
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: