I suppose this makes sense technically 😄. But working with types like this can be irksome since you have to do it consistently. Is there an end-user reason for this change?

I'm not opposed to it, just curious how it came up.

Oh hi 😄.

It's true that this isn't a random PR out of nowhere. I was reviewing mytypescript-eslint rule typings (I have only 4 of them and they are for a no-deadline personal project, which means that there's room for everything + the kitchen sink in it) and originally I had something like the following:

'@typescript-eslint/no-invalid-void-type'?:Linter.RuleEntry<[{allowInGenericTypeArguments?:string[]|boolean;allowAsThisParameter?:boolean;}]>;

I checkedno-invalid-void-type's documentation and noticed that the typing forallowInGenericTypeArguments had tightened up. For some reason (probably because I wanted to find out whether I can get rule typings directly fromtypescript-eslint source) I checked the rule source and noticed immediately that theOptions typing for it was out-of-date, largely because it's at the top of the file I guess.

Is there an end-user reason for this change?

I figured that the out-of-date typing would affect DX fortypescript-eslint itself, but after creating a test script inpackages/eslint-plugin/src (of thetypescript-eslint repo) and doing:

importrulesfrom'./rules';constaVar=rules['no-invalid-void-type'].create(/* ??? */);

I felt I was in a bit too deep to be comfortable, so instead of figuring out how thecreate method fits in the whole scheme of things, and then doing a "Complex Bug With a Reproduction" issue with my fork oftypescript-eslint as the repo, I figured that I'd just take my chances and go straight to a PR.

Got it, makes sense. It looks like this is the onlyminItems: 1 in a non-deprecated rule, so I guess you're setting a good precedent. Nice 😄