Fix tslint rules (plus a fix for every)
#5783
Conversation
| "max-classes-per-file": [true, 10], | ||
| "max-classes-per-file": [false, 1000], | ||
| // TODO: unified signatures not be disabled, but it will | ||
| // be a lot of work to verify the fixes don't mess something up. | ||
| "unified-signatures": [false], |
There was a problem hiding this comment.
thought: TBH, I don't agree with this rule anyway, so I'm happy to see it remain disabled. Sometimes separate signatures are clearer.
| @@ -1,7 +1,7 @@ | |||
| /** @prettier */ | |||
| import { Subscription } from '../Subscription'; | |||
|
|
|||
| type AnimationFrameProvider = { | |||
| interface AnimationFrameProvider { | |||
There was a problem hiding this comment.
thought: If this change from a type to an interface was effected by a lint rule, I would switch it off. Increasingly, types are able to due more and more. Personally, I would favour using interfaces only when they offer a feature that's not offered by a type. If it's a rule, I think it's a useless rule. Mostly because TypeScript has changed so much in the last few years.
There was a problem hiding this comment.
Hmmm... for me this was about just homogenizing the approach. FWIW: I think if we're just defining an interface (like one for a provider) than it should probably be an interface. However, if we're defining some sort of argument type that could be more than one thing, or a function shape, then I guess I'd prefer a type. But I suppose it's all personal preference.
- Gets rid of `Function` and `Object` use throughout the project.
…slint rule change botched it a bit
4db664b to
cdd9f27
Compare
TODOfor theunified-signaturesoverride, because I felt addressing that would be a minefield of type changes.everythat was uncovered by the removal of theprefer-constoverride, where we were not incrementing the index being passed to the predicate. Adds a test for that one.Consequently, this change also removes all usage of
Function, which I know @cartant hated passionately.Other thoughts:
eslintsoon.Arrayusage in a way that I personally agreed with, so that is still onvariable-namesbit is still on because it conflicts with the unused variables override of prefixing with an underscore.Note that commits labelled as
chorewere mostly non-changes. Just deleting a rule or an irrelevant bit of code or test.