False-positive jest/no-disabled-tests

[fabb]

In a non-test file (trackingXiti.ts), I have a function like this:

const mapPageViewEventName = (...) => {
    ....
    const map = xitiViewMap(...)
    ...
}

The rule warns about the line with the xitiViewMap function, probably because it starts with xit.

1. Shouldn't the jest rules only run on *.test.{js,tsx?} files?
2. The rule should match xit( and not xitSomethingElse(

[G-Rath]

Shouldn't the jest rules only run on *.test.{js,tsx?} files?

No, because jest doesn't require you to name your test files like that - you should be configuring eslint to only apply eslint-plugin-jest to your test files using overrides.

The rule should match xit( and not xitSomethingElse(

Correct - it's because our matcher is incorrect, I'll have a PR up shortly.

[fabb]

Would it be possible that the plugin reads jest.config.js to know which files it should consider?

[G-Rath]

We do hope to read the config one day to enhance the rules - see here for why that's currently not possible.

However, I don't think we'd do that for determining what files to run on, as that is exactly what you're meant to be using overrides for and some of our rules don't require being rule on files that jest runs as tests (i.e test helpers).

[fabb]

I‘m not completely sure how I should use overrides here, currently I‘m just using an /* eslint-disable jest/no-disabled-tests */ rule at the top of the (non-test) file. Would be nice If I could somehow generally declare which rules to enable for which files without having to specify it in the files themselves.

[G-Rath]

Would be nice If I could somehow generally declare which rules to enable for which files without having to specify it in the files themselves.

That's what exactly overrides is for :)

Here's one of my projects that uses overrides to apply the eslint-plugin-jest rules only to test files (via applying my company's jest shared config).

[fabb]

Ah nice, thanks! The first link above to overrides confused me.

[G-Rath]

No problem! it is currently a bit confusing - iirc the new config system that'll be coming over the next year or so includes refactoring the config to be "override based" which should be better - so instead of having rules & overrides, the config is more like having overrides as the top-level, so it'll be a lot more obvious and natural to point your rules at specific files via paths.