test: migrate to createRuleTestCaseFunction

[marcalexiei]

I migrated the first 10 rules test files.

Aside from a fix on first rule where value was missing in Options type everything should work like a charm.
(I added a changeset but unless someone is extracting the type from the rule export nothing will change on user land)

Do you prefer that I continue to push on this PR or do you prefer that I open subsequent PRs to divide the review effort?

[changeset-bot]

🦋 Changeset detected

Latest commit: 5247ee5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
eslint-plugin-import-x	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[SukkaW]

Do you prefer that I continue to push on this PR or do you prefer that I open subsequent PRs to divide the review effort?

You can either continue to push to this PR or do subsequent PRs, I am OK with both.

If you are going to continue to push to this PR, it would be better to convert this PR to a draft.

[marcalexiei]

I discovered a type issue with createRuleTestCaseFunction:
in some scenarios the return type is ValidTestCase rather than InvalidTestCase.

e.g.:

test({
  code: "import * as namespace from './malformed.js';",
  errors: [{ messageId: 'computedReference' }]
})

This was caused by the TTestCase declared inside factory signature rather than in the returned signature. If we move the TTestCase in the returned function, alongside TReturn, autocomplete and type checking won't work like they should.

I haven't discovered this earlier because the returned function was inferring the parameter from RuleTester or from the variable type
(e.g.: const valid: RunTests<typeof rule>['valid'])

---

Another issue related to the wrong return was that valid case with errors were not reported by typecheck.
See these two examples on the main branch:

eslint-plugin-import-x/test/rules/named.spec.ts

Lines 182 to 185 in 14fc608

	test({
	code: 'const { baz } = require("./bar")',
	errors: [error('baz', './bar')],
	}),

eslint-plugin-import-x/test/rules/named.spec.ts

Lines 187 to 191 in 14fc608

	test({
	code: 'const { baz } = require("./bar")',
	errors: [error('baz', './bar')],
	options: [{ commonjs: false }],
	}),

You can see that both case are inside a valid array.

A possible solution to the problem

A less complex and more straightforward solution is to make a helper
function returning two functions: one for valid case and one for invalid cases.

const { tValid, tInvalid } = createRuleTestCaseFunctions<typeof rule>();

Helper implementation

export function createRuleTestCaseFunctions<
  TRule extends RuleModule<string, unknown[]>,
  TData extends GetRuleModuleTypes<TRule> = GetRuleModuleTypes<TRule>,
  Valid = TSESLintValidTestCase<TData['options']>,
  Invalid = TSESLintInvalidTestCase<TData['messageIds'], TData['options']>,
>(): { tValid: (t: Valid) => Valid; tInvalid: (t: Invalid) => Invalid } {
  return {
    tValid: createRuleTestCase as never,
    tInvalid: createRuleTestCase as never,
  }
}

This way we can be sure that

1. the test case is correctly type checked
2. autosuggestion works as they should
3. return type is constant with the testcase

[marcalexiei]

Note

I already applied the last proposed changes with the last commit since they required less time than I thought!
Looking forward to your feedback.

[marcalexiei]

Found other two ValidTestCase with errors in no-dynamic-require.spec.ts

eslint-plugin-import-x/test/rules/no-dynamic-require.spec.ts

Line 122 in 14fc608

errors: [dynamicImportError],

eslint-plugin-import-x/test/rules/no-dynamic-require.spec.ts

Line 132 in 14fc608

errors: [dynamicImportError],

Note

Now I'll really stop until your review 😅
I have few minutes and I migrated few more rules to further check the new proposed approach.

[SukkaW]

Now I'll really stop until your review 😅 I have few minutes and I migrated few more rules to further check the new proposed approach.

Actually, I have always been reviewing. As far as I can see there is no issue here. Let's keep moving~

[SukkaW]

I have reviewed all the changes so far, LGTM for now!

[SukkaW]

Be advised, I just upgraded a few deps and changed a few codes. You might wanna rebase if it is going to introduce conflicts to your side.

[marcalexiei]

There are no conflicts but CI is failing on master.

Probably is related to the changes on RuleTester#run function using NoInfer (typescript-eslint/typescript-eslint#10324).

Those error should be fixed with the new approach I'm using here, I'll try to finish the few rules left and then perform a rebase.

[marcalexiei]

• all tests have been migrated to the new createRuleTestCaseFunction approach
• the branch has been rebased on master
• I had to apply some ESLint fixes coming from eslint-plugin-unicorn update.
  They are in a separate commit so let me know if I need to add a changeset or if we need to revert some of the changes.