[Bug]: "Runner is not a constructor" when using nested relative path and Yarn

[G-Rath]

Version

30.0.3

Steps to reproduce

1. Clone https://github.com/G-Rath/jest-runner-bug
2. Run yarn install
3. cd into foo/bar/dip
4. Run npx jest

Alternatively, see the CI: https://github.com/G-Rath/jest-runner-bug/blob/main/.github/workflows/ci.yml & https://github.com/G-Rath/jest-runner-bug/actions/runs/15981985791/job/45078225921

Expected behavior

Jest to be happy

Actual behavior

Jest errors about "Runner is not a constructor"

Additional context

This was found via jest-community/jest-runner-eslint#291 where I've already done some digging, and spoken to @JounQin about - originally we were not sure if this is actually something Jest officially supports, but now that I know it only seems to happen on Yarn and when nested more than two directories I think it's clearly a bug.

The issue seems to lie with jest-resolve and/or unrs-resolver - see this comment for the work I've done so far

Environment

System:
    OS: Linux 6.6 Ubuntu 22.04.5 LTS 22.04.5 LTS (Jammy Jellyfish)
    CPU: (20) x64 13th Gen Intel(R) Core(TM) i7-13700H
  Binaries:
    Node: 20.19.0 - ~/.nodenv/versions/20.19.0/bin/node
    Yarn: 1.22.22 - ~/.nodenv/versions/20.19.0/bin/yarn
    npm: 10.8.2 - ~/.nodenv/versions/20.19.0/bin/npm

[G-Rath]

Note that @ljharb considers this a blocker to release Jest v30 support for jest-runner-eslint

[ljharb]

Technically I don't think it's a blocker but it'd be nice to not have to work around this bug forever :-)

[SimenB]

I agree with Jordan, fwiw (as in - this is a bug that should be fixed, not worked around downstream)

[G-Rath]

To be clear, this bug only affects the test suite for jest-runner-eslint, it does not impact using the runner with Jest v30 downstream.

I agree that it would be good to get it resolved in Jest but I don't think it should block the actual release of Jest v30 support in the meantime

[JounQin]

I'll take a look soon later.

[JounQin]

@G-Rath I have no idea with what's happening, yarn jest works, npx jest doesn't work, the path are different between them: jest-runner-./ vs jest-runner-../../../.

I even don't where ../../../ is generated with npx.

---

[JounQin]

OK, the root cause is:

jest/packages/jest-config/src/normalize.ts

Line 64 in 7250950

const requireResolve = (module: string) => require.resolve(module);

which is used at

jest/packages/jest-resolve/src/utils.ts

Line 60 in 7250950

return requireResolveFunction(`${prefix}${fileName}`);

And

console.log("requireResolve('jest-runner-../../../')", requireResolve('jest-runner-../../../'))

// requireResolve('jest-runner-../../../') /Users/JounQin/Workspaces/GitHub/jest-runner-bug/node_modules/jest-config/build/index.js

I don't know Node.js require support like this, LOL.

And with npm installation:

console.log("requireResolve('jest-runner-../../../')", requireResolve('jest-runner-../../../'))

// requireResolve('jest-runner-../../../') /Users/JounQin/Workspaces/GitHub/jest-runner-bug/runner.js

@G-Rath So I think this is a bit out of scope, you should use yarn jest for yarn installation, npx jest for npm installation, don't mix them together.

Although I don't know why they're working different.

[G-Rath]

@JounQin I'll defer to @SimenB on the final decision about if this is going to be classed not a bug in Jest, but a few points:

• because this works in v29 it's technically a breaking change
• this happens when using node_modules/.bin as well as when using npx
  • this is how jest-runner-eslint is actually running Jest, using execa
  • I've updated my reproduction repo to also show this: https://github.com/G-Rath/jest-runner-bug/commit/5a7b9f02167febb915681056b23ce4404f90eccc

[ljharb]

weird because npx should be checking node_modules/.bin first, and doing mostly the same thing as calling it directly.

[JounQin]

@ljharb Do you think resolving jest-runner-../../../ successfully is following Node spec or just a undefined behavior?

[JounQin]

The key difference here is unrs-resolver doesn't resolve jest-runner-../../../ same as require itself, but I need to understand whether it's spec compliant behavior.