feat(eslint-plugin-jest): addvalid-expect rule

[eryue0220]

Summary

• Port valid-expect from eslint-plugin-jest to rslint.

Related Links

Tracking issue: #476
eslint-plugin-jest/valid-expect doc code

Checklist

• Tests updated (or not required).
• Documentation updated (or not required).

[gemini-code-assist]

Code Review

This pull request implements the jest/valid-expect rule, which ensures that expect() calls in Jest tests have the correct number of arguments, are followed by a matcher call, and that async assertions are properly awaited or returned. The implementation includes the rule logic, documentation, and comprehensive test suites in both Go and TypeScript. Feedback was provided regarding the tooManyArgsRange function, where decrementing the end position may result in inaccurate diagnostic highlights in the UI due to how AST node end positions are typically handled.

[gemini-code-assist]

The end-- logic here is likely incorrect. In Go's AST, End() returns the position immediately after the last character of the node (exclusive). By decrementing end, the reported range will exclude the last character of the last extra argument, leading to an inaccurate diagnostic highlight in the UI. Ensure the implementation maintains exact alignment with ESLint's semantics and uses UTF-16 code units for LSP compatibility.

return core.NewTextRange(start, end)

References

1. For linter rules ported from or inspired by ESLint, maintain exact alignment with ESLint's semantics, even for edge cases where a simpler implementation might seem practically equivalent.
2. For LSP compatibility, calculate string character positions by counting UTF-16 code units, not bytes or runes. Characters outside the BMP (e.g., emoji) count as two units.

[fansenze]

reportUncalledMatcherMember fires for any member chain whose first segment is literally expect, even when expect itself was never called — upstream only has a CallExpression listener, so a bare member access is never visited.

expect.extend;    → upstream: no error | here: matcherNotCalled
expect.resolves;  → upstream: no error | here: matcherNotFound

Only assertions/hasAssertions are exempted, so every other bare expect.x is a false positive.

[fansenze]

findPromiseCallExpressionNode walks every ancestor up to the function boundary; upstream only inspects node.parent (and the grandparent for an ArrayExpression), so this latches onto a Promise.* call upstream would never reach.

Promise.all([ foo(expect(Promise.resolve(2)).resolves.not.toBeDefined()) ])
  upstream: asyncMustBeAwaited on the assertion
  here:     promisesWithAsyncAssertionsMustBeAwaited on Promise.all  (wrong node + messageId)

And await Promise.all([ foo(expect(...)) ]) climbs to the awaited Promise.all and reports nothing, while upstream still flags the un-awaited inner assertion (missed report).

[fansenze]

isExpectChain matches the literal name "expect" before ParseJestFnCall runs, so aliased imports are never resolved. Other jest rules (prefer-to-contain, no-standalone-expect) support this alias.

import { expect as pleaseExpect } from '@jest/globals'; pleaseExpect(p).resolves.toBe(2)
  upstream: asyncMustBeAwaited
  here:     nothing (missed report)

[fansenze]

Here parsed == nil can't distinguish "not jest's expect" from "malformed expect chain": isExpectChain passes on the name, ParseJestFnCall returns nil for a non-jest expect, and this block re-derives a reason and reports anyway.

import { expect } from 'chai'; expect(foo).to.equal(bar)
  upstream: no error (resolveToJestFn returns null for a non-jest expect)
  here:     modifierUnknown (false positive)

This and the isExpectChain gate above would both be fixed by reusing a three-state parse entry (parsed / reason / not-jest-null) like upstream's parseJestFnCallWithReason, instead of a name-gate plus reporting-on-nil.