Repo: Rule [options] parameter should be non-nullable if defaultOptions exists

[JoshuaKGoldberg]

Suggestion

Right now, if a rule is created through util.createRule with defaultOptions, the create function's second parameter is an array whose first element is still Options | undefined. That means folks have to !. For example, in #5327:

typescript-eslint/packages/eslint-plugin/src/rules/lines-around-comment.ts

Lines 136 to 137 in 7f2661f

	create(context, [_options]) {
	const options = _options!;

Unless I've grossly misinterpreted the rule options, those ! should be unnecessary, right?

Edit: here's a TypeScript playground with an isolated repro.

[JoshuaKGoldberg]

We've deleted lines-around-comment in the v8 branch. A new still-in-the-repo example is consistent-type-imports:

typescript-eslint/packages/eslint-plugin/src/rules/consistent-type-imports.ts

Lines 89 to 98 in e408b93

	defaultOptions: [
	{
	prefer: 'type-imports',
	disallowTypeAnnotations: true,
	fixStyle: 'separate-type-imports',
	},
	],
	create(context, [option]) {
	const prefer = option.prefer ?? 'type-imports';

[JoshuaKGoldberg]

#9025 touches a lot of the same interfaces, so marking as blocked on that one till it's merged.

Edit: ready to go 🙂

[JoshuaKGoldberg]

I took a run at this today. It was, as expected, very tricky to try to get to work. Removing from the v8 milestone as there are two upstream ecosystem work items that could land first:

• feat: add meta.defaultOptions eslint/eslint#17656: which may totally change how we'd want to handle default options anyway
• Implement partial type argument inference using the _ sigil microsoft/TypeScript#26349, per the note in RuleCreator

On that latter list item, RuleCreator's createNamedRule is pretty complex right now:

typescript-eslint/packages/utils/src/eslint-utils/RuleCreator.ts

Lines 59 to 64 in b1c92d4

	// This function will get much easier to call when this is merged https://github.com/Microsoft/TypeScript/pull/26349
	// TODO - when the above PR lands; add type checking for the context.report `data` property
	return function createNamedRule<
	Options extends readonly unknown[],
	MessageIds extends string,
	>({

Having to add a potential third type parameter for OptionDefaults is ... even more complexity. Especially since we currently sometimes need to be explicit about types in createRule calls:

typescript-eslint/packages/eslint-plugin/src/rules/no-floating-promises.ts

Line 52 in 04990d5

export default createRule<Options, MessageId>({

Marking as blocked on external items. 😞