refactor: Strengthen Type Safety and Fix Test File Compilation Errors

[y-hsgw]

It's a minor change, but I refactored a few parts that caught my attention. Please feel free to close this PR if it doesn't meet your expectations. I appreciate your review!

Checks

• I have read the contributing guidelines.

Changes

• update test case types to use rule-tester types.
  → Due to deprecation of TSESLint's InvalidTestCase and ValidTestCase.

• apply as const for stricter type safety on query definitions.

• add explicit return type to createTestingLibraryRule for better type safety.
  → Because a type error occurred in test files when passing the rule as the second argument to ruleTester.run.

Context

[codecov]

Codecov Report

Attention: Patch coverage is 96.77419% with 1 line in your changes missing coverage. Please review.

Project coverage is 96.28%. Comparing base (26d360e) to head (a90211d).
Report is 22 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/create-testing-library-rule/index.ts	85.71%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1015   +/-   ##
=======================================
  Coverage   96.27%   96.28%           
=======================================
  Files          46       47    +1     
  Lines        2472     2531   +59     
  Branches     1025     1047   +22     
=======================================
+ Hits         2380     2437   +57     
- Misses         92       94    +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Belco90]

Thanks for taking care of this! Just added some comments.

[Belco90]

question(blocking): Why? I don't fully understand the reason to return docs within meta if it was already there.

[y-hsgw]

I’m explicitly specifying docs because the following code results in a type error:

return { ...rule, meta: { ...rule.meta } };

Type '(TestingLibraryPluginDocs & RuleMetaDataDocs) | undefined' is not assignable to type 'TestingLibraryPluginDocs & RuleMetaDataDocs'.
Type 'undefined' is not assignable to type 'TestingLibraryPluginDocs'.

[Belco90]

But why not returning just rule?

[y-hsgw]

rule.meta.docs is marked as optional in the return type of ESLintUtils.RuleCreator,
whereas rule.meta.docs is required in TestingLibraryPluginRuleModule<TMessageIds, TOptions>.
So I'm narrowing the type explicitly to ensure it satisfies the expected structure.

If we return rule directly, we get the following type error:

Type 'RuleModule<TMessageIds, TOptions, TestingLibraryPluginDocs, RuleListener>' is not assignable to type 'TestingLibraryPluginRuleModule<TMessageIds, TOptions>'.
Types of property 'meta.docs' are incompatible.
Type '(TestingLibraryPluginDocs & RuleMetaDataDocs) | undefined' is not assignable to type 'TestingLibraryPluginDocs & RuleMetaDataDocs'.
Type 'undefined' is not assignable to type 'TestingLibraryPluginDocs & RuleMetaDataDocs'.
Type 'undefined' is not assignable to type 'TestingLibraryPluginDocs'.ts(2322)

[Belco90]

question(blocking): Why removing the node.property condition from this if statement? It worked as short-circuiting the evaluation of the expression.

[y-hsgw]

I initially tried implementing it like this:

if (
  ASTUtils.isIdentifier(node.property) &&
  ALL_RETURNING_NODES.some(
    (allReturningNode) => allReturningNode === node.property.name
  )
)

However, accessing node.property.name caused a type error:

Property 'name' does not exist on type 'PrivateIdentifier | Expression'.
Property 'name' does not exist on type 'MemberExpressionComputedName'.

That’s why I went with the current approach instead.

[Belco90]

But now that you already checked that ASTUtils.isIdentifier(node.property) for extracting the propertyName, you could use that for the condition:

if (
  propertyName &&
  ALL_RETURNING_NODES.some(
    (allReturningNode) => allReturningNode === propertyName
)

[y-hsgw]

Personally, I thought the propertyName && check was unnecessary, since the comparison inside some — allReturningNode === propertyName — would implicitly return false if propertyName is null.

But you're right — adding the explicit condition improves readability, so I updated it in a90211d.