prefer-expect-assertions conflicts with no-magic-numbers

[electriquo]

There's a conflict when using eslint-plugin-jest's prefer-expect-assertions rule alongside ESLint's core no-magic-numbers rule. Here's a simple example:

test('some test', () => {
  expect.assertions(1); // should NOT trigger no-magic-numbers
  const result = someFunction(42); // SHOULD trigger no-magic-numbers
  expect(true).toBeTruthy();
});

The call to expect.assertions(1) is semantically meaningful and encouraged by prefer-expect-assertions, yet it's flagged by no-magic-numbers due to the numeric literal.

I raised this issue with the ESLint maintainers here: eslint/eslint#19956, but the response was:

As stated in the docs, this rule is currently frozen and is not accepting feature requests. You can always copy the rule source code into your custom rule and modify it to fit your needs.

Rather than creating a custom rule, and since I believe this conflict affects many others, it would be great if this functionality could be integrated into eslint-plugin-jest, if feasible.

Possible Solutions

• Ignore magic numbers specifically inside expect.assertions(<number>)
• Or, provide a config option like ignoreAssertionCounts: true

This would maintain alignment between Jest best practices and ESLint rules without forcing unnecessary suppression or duplication.

Thanks for considering this!

[G-Rath]

I personally am not particularly motivated to have this as I've never been convinced that no-magic-numbers leads to more maintainable code and I feel like that is especially true in tests where the use of literal numbers are most likely either associated with a comment or test title that explains why they're important or they're random because the actual number doesn't matter.

I would also expect this to apply to other similar situations (e.g. Vitest) so if its affecting a lot of others we could end up with the same rule being duplicated in a number of plugins, and that could even make it worth actually unfreezing the core rule.

This is an open-source project so I'm not saying outright "no", but I'd prefer at least knowing a number of people would find this useful to justify taking it on here

[electriquo]

Thank you @G-Rath for the reply. For the time been, I've wrapped no-magic-number rule to handle this case, and used it in favor of the original one.