Skip to content

feat(eslint-plugin-jest): add prefer-strict-equal rule#623

Open
eryue0220 wants to merge 5 commits intoweb-infra-dev:mainfrom
eryue0220:feat/jest-prefer-strict-equal
Open

feat(eslint-plugin-jest): add prefer-strict-equal rule#623
eryue0220 wants to merge 5 commits intoweb-infra-dev:mainfrom
eryue0220:feat/jest-prefer-strict-equal

Conversation

@eryue0220
Copy link
Copy Markdown
Contributor

Summary

Port prefer-strict-equal from eslint-plugin-jest to rslint.

Related Links

Tracking issue: #476
eslint-plugin-jest/prefer-strict-equal doc code

Checklist

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

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a new Jest linting rule, prefer-strict-equal, which promotes the use of toStrictEqual() over toEqual() in expect() calls. The review identifies a bug where the rule incorrectly flags expect().not.toEqual() and provides a code suggestion to fix this by checking for the .not modifier. Additionally, it suggests adding test cases for this not modifier scenario in both the Go and TypeScript test suites to ensure correct behavior. The review also recommends enhancing the rule's documentation to provide a more detailed explanation of why toStrictEqual() is preferred, specifically regarding its handling of undefined properties.

eryue0220 and others added 4 commits April 10, 2026 18:50
…equal.md

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Comment on lines +43 to +45
if kind != ast.KindIdentifier && kind != ast.KindStringLiteral {
continue
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getElementAccessName in jest.go also supports ast.KindNoSubstitutionTemplateLiteral, which means expect(x)[toEqual](y) will produce a MemberEntry with Name: "toEqual" and Node.Kind: NoSubstitutionTemplateLiteral. This filter skips it silently, so the rule won't report on template-literal bracket access.

if kind != ast.KindIdentifier && kind != ast.KindStringLiteral && kind != ast.
KindNoSubstitutionTemplateLiteral {
    continue
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants