This recommendation makes sense for Jest which has a toHaveLength matcher. We, however, use Jasmine, which doesn’t. Can something be done about this? Should I just disable the rule? I wanted to read the docs to figure out if this rule monitors other matchers which I wouldn’t want to turn off reporting for, but I can’t seem to be able to access the rule docs:
When on this page and clicking on any rule, e.g. prefer-specific-assertions, I get a GitHub login prompt if I’m not logged in and an “Unauthorized access errror” if I am. Could you look into this as well?
Thanks for the report. I investigated this, and you’re right that this should not be suggested for a Jasmine assertion.
S5906 has specific handling for Jasmine and should suggest toHaveSize when the detected Jasmine version supports it. However, if the project dependencies include both Jasmine and a Jest-like dependency, such as jest, vitest, or @jest/globals, a bare global expect(...) can be classified as Jest-like first. In that case, the rule suggests Jest’s toHaveLength, even though the assertion is actually using Jasmine.
Could you check whether the nearest package.json, or a parent workspace package.json, contains any Jest-like dependency in addition to Jasmine? If so, that would explain the behavior. We’ll need to adjust the rule so it handles this mixed-dependency setup correctly.
This should be fixed for the next release.
Regarding the documentation links, the rule specification repository was recently made private, this explains why you don’t have access.
I confirm that we have both jasmine & jest installed. Our global types are those of jasmine (with @types/jasmine) installed, we have to explicitly import all API functions like expect, describe , etc from @jest/globals in jest files, or the typings will be wrong.
I don’t know whether the rule can be taught to handle setups like this without becoming too convoluted: I imagine we could well have the Jest types as the globally available ones and Jasmine types only after explicitly importing them.
A good solution could also be to file a feature request with Jasmine that a toHaveLength matcher be added. I’ll let you decide.
