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 my typescript-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 checked no-invalid-void-type's documentation and noticed that the typing for allowInGenericTypeArguments had tightened up. For some reason (probably because I wanted to find out whether I can get rule typings directly from typescript-eslint source) I checked the rule source and noticed immediately that the Options 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 for typescript-eslint itself, but after creating a test script in packages/eslint-plugin/src (of the typescript-eslint repo) and doing:

import rules from './rules';
const aVar = rules['no-invalid-void-type'].create(/* ??? */);

I felt I was in a bit too deep to be comfortable, so instead of figuring out how the create method fits in the whole scheme of things, and then doing a "Complex Bug With a Reproduction" issue with my fork of typescript-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 only minItems: 1 in a non-deprecated rule, so I guess you're setting a good precedent. Nice 😄