Is jest really a peer (optional) dependency? It isn't because of the "'jest/no-deprecated-functions': Unable to detect Jest version" error.

[stephen-carter-at-sf]

Background - see salesforce/eslint-config-lwc#161

Should 'jest/no-deprecated-functions' really error if jest isn't installed?

This rule is causing other plugins and configs to not be used when jest isn't installed.

For example, https://github.com/salesforce/eslint-config-lwc is a popular eslint config that salesforce developers use to validate their salesforce lightning web components. But not all salesforce developers have jest installed. Some might have vitest, or a different test framework, or none at all. But the owners of @salesforce/eslint-config-lwc wanted to add in the jest rules into their recommended config just in case a user does have tests - jest tests in particular. But if they don't - it would be expected that these rules just wouldn't run or wouldn't produce violations or whatever.

But because eslint-plugin-jest is listed as a plugin within the @salesforce/eslint-config-lwc config, then it errors as shown in salesforce/eslint-config-lwc#161.

The reason why this seems wrong is because jest is listed as a "peerDependency" of eslint-plugin-jest - specifically with the "optional" true marker.

So this seems like a bug with that rule.

[wjhsf]

This seems to be an issue with just the jest/no-deprecated-functions rule. I set up a repro by running npm install eslint@9.38.0 eslint-plugin-jest@29.0.1 and using the eslint.config.js below. Running npx eslint fails with an error when jest/no-deprecated-functions is enabled, but passes when it is disabled.

// eslint.config.cjs
const all = require("eslint-plugin-jest").configs["flat/all"]
module.exports = {
  ...all,
  rules: {
    ...all.rules,
    // eslint fails with jest/no-deprecated-functions enabled (via `all`),
    // but passes when it is disabled
    // "jest/no-deprecated-functions": "off"
  }
}

> npx eslint          

Oops! Something went wrong! :(

ESLint: 9.38.0

Error: Error while loading rule 'jest/no-deprecated-functions': Unable to detect Jest version - please ensure jest package is installed, or otherwise set version explicitly
Occurred while linting /Users/wharney/git/tmp/eslint.config.cjs
    at detectJestVersion (/Users/wharney/git/tmp/node_modules/eslint-plugin-jest/lib/rules/utils/detectJestVersion.js:22:9)
    at create (/Users/wharney/git/tmp/node_modules/eslint-plugin-jest/lib/rules/no-deprecated-functions.js:31:107)
    at Object.create (/Users/wharney/git/tmp/node_modules/@typescript-eslint/utils/dist/eslint-utils/RuleCreator.js:31:20)
    at createRuleListeners (/Users/wharney/git/tmp/node_modules/eslint/lib/linter/linter.js:1019:15)
    at /Users/wharney/git/tmp/node_modules/eslint/lib/linter/linter.js:1151:7
    at Array.forEach (<anonymous>)
    at runRules (/Users/wharney/git/tmp/node_modules/eslint/lib/linter/linter.js:1085:31)
    at #flatVerifyWithoutProcessors (/Users/wharney/git/tmp/node_modules/eslint/lib/linter/linter.js:2101:4)
    at Linter._verifyWithFlatConfigArrayAndWithoutProcessors (/Users/wharney/git/tmp/node_modules/eslint/lib/linter/linter.js:2189:43)
    at Linter._verifyWithFlatConfigArray (/Users/wharney/git/tmp/node_modules/eslint/lib/linter/linter.js:2292:15)

[G-Rath]

This is by design since the rule needs to know the version of Jest you're targeting to do anything so having it enabled without a Jest version is an error - as for the optional peer dependency, that is because we support resolving Jest automatically but you can also provide the version explicitly per the error message

[stephen-carter-at-sf]

@G-Rath This design is bad is what we are saying. It shouldn't kill the entire ESLint run. Instead it should at best just report itself as a soft warning or violation. No 1 rule should bring down the ship... especially within the world of sharable flat config files (where the plugin is added but it may not always be applicable to the users workspace).

@G-Rath Also, our users do have jest installed and yet this rule errors out simply because it can't find it for some reason. Latest issue: forcedotcom/code-analyzer#1929

[G-Rath]

@stephen-carter-at-sf not erroring risks incorrect results, and if you want to ensure an error doesn't get raised, you can easily take care of the resolution logic yourself especially now that we have flat config which is JS-based.

Also while currently the value is only being used by one rule, this is actually about a plugin-level setting.

Pretty much all of the alternatives here would have us emit output for every single file linted by every rule that used this setting which would be very noisy and far more unhelpful.

where the plugin is added but it may not always be applicable to the users workspace

Our rules should only ever be used in applicable situations - we do not promise that it is safe to run our rules on files that are not for Jest.

our users do have jest installed and yet this rule errors out simply because it can't find it for some reason

If you open a reasonably contained reproducible example of a situation where our auto setting is not finding Jest, I'll happily look into it.

[wjhsf]

In #1849, I updated the rule to default to the latest version if no version is detected. This may have false positives, but anyone currently using the rule without jest is already broken, so this is still an improvement.

In #1850, I updated the rule to provide an error message when jest is not detected. This allows eslint to proceed as expected if no rule violations are detected.

[G-Rath]

@wjhsf please do not open PRs when there is clear disagreement on the change - as it is, your changes are breaking since users that are not on the latest Jest will start getting false positives.

fwiw, @typescript-eslint also throws an error when you attempt to use a type-based rule without it being properly setup so this behaviour is not unique to us.