Fix: Bubble up file tree to find jest

[codejedi365]

Problem

I ran into an breaking error when trying to run eslint at the root level of a monorepo and the jest plugin was used by a submodule and only loaded within the submodule context.

Monorepos desire to run test/lint functionality from the root folder rather than all submodules which can cause conflicts with what the process.cwd() is set to.

Error log:

$ npm run lint

> lint
> eslint . --ext ts,js,json,md,mdx,.remarkrc

Oops! Something went wrong! :(

ESLint: 7.32.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/me/dev/project/core/client/.eslintrc.js
    at detectJestVersion (/Users/me/dev/project/core/client/node_modules/eslint-plugin-jest/lib/rules/no-deprecated-functions.js:39:9)
    at create (/Users/me/dev/project/core/client/node_modules/eslint-plugin-jest/lib/rules/no-deprecated-functions.js:62:256)
    at Object.create (/Users/me/dev/project/core/client/node_modules/@typescript-eslint/experimental-utils/dist/eslint-utils/RuleCreator.js:13:24)
    at createRuleListeners (/Users/me/dev/project/node_modules/eslint/lib/linter/linter.js:765:21)
    at /Users/me/dev/project/node_modules/eslint/lib/linter/linter.js:937:31
    at Array.forEach (<anonymous>)
    at runRules (/Users/me/dev/project/node_modules/eslint/lib/linter/linter.js:882:34)
    at Linter._verifyWithoutProcessors (/Users/me/dev/project/node_modules/eslint/lib/linter/linter.js:1181:31)
    at Linter.<anonymous> (/Users/me/dev/project/node_modules/eslint-plugin-json-format/lib/index.js:48:28)
    at Linter._verifyWithConfigArray (/Users/me/dev/project/node_modules/eslint/lib/linter/linter.js:1280:21)

With a little debugging, I was able to identify the following variables were currently set to:

__dirname = '/Users/me/dev/project/core/client/node_modules/eslint-plugin-jest/lib/rules'
process.cwd() = '/Users/me/dev/project/'

# actual location
require.resolve('jest') = '/Users/me/dev/project/core/client/node_modules/jest'

My project was laid out:

project/
  |-> core/
  |     |-> client/
  |     |     |-> .eslintrc.js                # loads eslint-plugin-jest for unit-tests
  |     |     '-> package.json                # devDependencies: { "jest", "eslint-plugin-jest" }
  |     |-> server/
  |           '-> package.json                # no jest
  |-> .eslintrc.js
  |-> package.json       # devDependencies: { "eslint" }, no jest
                         # scripts: { "lint": "eslint . --ext ts,js,json,md,mdx,.remarkrc" }

Alternatives

1. Define jest version statically in the root package.json as a configuration option. I would rather not do this since I would have to keep the definition in sync from the root project and the submodule's package definition.

Solution

This small loop bubbles up the file tree when it detects the edge case where the eslint-plugin-jest module is installed in a submodule's dependencies only and the process.cwd() does not directly match.

[SimenB]

You can use an .eslintrc.js and do your own require in it. I think that's cleaner than trying to be more clever in this plugin.

@G-Rath thoughts?

[codejedi365]

@SimenB, Thanks for the quick reply.

You can use an .eslintrc.js and do your own require in it.

I'll need more information and an example of this. I don't anticipate this would solve my issue since it is specifically the eslint-plugin-jest module performing the require().

I would also request you to reconsider the "cleverness" because the current code also assumes that the eslint command is being called from the environment of an npm run-script where the CWD is guaranteed to be a package root.

[G-Rath]

@G-Rath thoughts?

I think this patch has us being too clever - we attempt to find jest as a nicety but also purposely take in the jest version as an option so that projects with unexpected structures can handle this path resolving themselves (as you say with having a .eslintrc.js + require).

However I do think I was silly to include process.cwd() in the paths - I can't remember why I did that originally, but I've done some light testing with IntelliJ and it's not broken so 🤷

@codejedi365 could you see if you still have issues if you remove the paths completely?

I don't anticipate this would solve my issue

It will, because our require is only performed if the rule isn't being provided with the jest version - so your .eslintrc.js would do what your patching is trying to do and we'd take that as is.

[codejedi365]

@G-Rath

@codejedi365 could you see if you still have issues if you remove the paths completely?

I did remove paths completely and it actually ran successfully! I'll adjust my PR shortly to use this similar fix. I suspected node's require.resolve() bubbles up the paths properly anyway.

[G-Rath]

@codejedi365 I've already got a PR opened for this, but it's also made me realised that the larger bit of work we have to do is adjusting our tests (which I now suspect is why I had it there in the first place, since it appeared like it was working)

Are you ok if I close this PR in favor of #889?

[codejedi365]

Are you ok if I close this PR in favor of #889?

@G-Rath, yes I am. I'll keep track of that one until resolution, thank you.

[github-actions]

🎉 This issue has been resolved in version 24.5.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 25.0.0-next.5 🎉

The release is available on:

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

Your semantic-release bot 📦🚀