Allow addditional assert function names with expect-expect

[sarayourfriend]

Fixes #154.

This PR does not attempt parity with the eslint-plugin-jest rule option. It would not necessarily be difficult to achieve parity. The jest plugin is MIT licensed and we could copy/paste the various utility functions from that library to implement a similarly flexible option.

I've opted not to do that because this naive approach was very simple to implement and I wanted to get the PR up for it in case it's an acceptable MVP for this change. However, if y'all would like me to extend it to add full parity with the jest plugin's rule's options, I am happy to do so, just let me know.

[gilmeir-arnac]

+1 for customized function names for assertions enforcement, that's exactly what I was looking for 🙏

[sarayourfriend]

@mskelton Can you advise whether this approach is acceptable or if you'd prefer 1:1 parity with the jest plugin's rule configuration?

[mskelton]

Sorry, haven't had a chance for review. I think what I would actually prefer would be to use global settings so that we can share those settings for all rules that are checking expect statements. Similar to this:

https://github.com/jest-community/eslint-plugin-jest#aliased-jest-globals

[sarayourfriend]

Sounds good, I'll draft this and hope to return to work on it later this week.

[sarayourfriend]

@mskelton I've got a working implementation based on shared data. However, there are two problems I'd like to clarify:

• The expansion of valid assert functions really only applies to expect-expect. valid-expect, for example (the other obvious callsite of isExpectCall) only refers to actual usages of expect. Custom assertion functions couldn't be evaluated by valid-expect without heaps more configuration. In a sense valid-expect ensures that calls to expect actually create assertions. Allowing custom assert function names in expect-expect is a bit circuitous. A better overall rule might be a combination of both expect-expect and valid-expect that accepts custom assertion function names, named something like expect-assertion. valid-expect essentially ensures the assertion, while expect-expect just ensures that some call to expect is made, regardless of whether there is an assertion. I'm not suggesting a big refactor here to combine the rules or anything, just to suggest that I'm sceptical of the wider use case of configuring assertion functions in shared data if the reason is to make them available to other rules that evaluate assertions, specifically because there aren't other rules that a generic plugin could have that could apply to custom assertion functions.
• Using only shared data to configure the list of additional assertion function names has some limitations, primarily that a module-specific assertion function would need to be configured in the global ESLint configuration rather than at the module level using the /* eslint <rule name>: <options> */ pragma available for rule options. I'd suggest we should use both. It is very convenient to have a global list of additional assertion functions, especially one that persists even if specific modules need to expand the list (using just rule options means globally configured options would need to be repeated in modules if they're needed there, not ideal). But needing to define a reusable assertion function in the global list that is only relevant to a particular module is tedious and leaks module-specific details into the global configuration. Would you be open to the PR including both shared data-based configuration and rule options-based configuration? This is predicated on me not having been able to find any way to modify shared data on a module-specific level. If that is possible, then forgive me ignorance and ignore this bit. It's also only relevant if you agree that the additional assertion function names is only applicable to expect-expect in the first place.

[sarayourfriend]

@mskelton Any thoughts regarding my question above? Are you okay with taking the dual approach, allowing for both adding assert function names that should be considered valid in all modules as well as the rule-specific configuration, to allow to extending the list in a given module?

[mskelton]

@sarayourfriend Sorry, I forgot to reply to this thread. I think I agree that doing both is probably best. Global config that can be overridden per rule.

[sarayourfriend]

No worries, thanks for confirming. I'll try to have the PR ready be the end of the week.

[sarayourfriend]

This PR should be ready for another review @mskelton 🙏

[sarayourfriend]

@mskelton Your requests are addressed in the most recent commit.

[github-actions]

🎉 This PR is included in version 0.16.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀