Confirming drawback with use in a monorepo

[jtlapp]

REVISED

I love this test runner and have spent considerable time trying to get it to work with my monorepo. I do have it working now, but it seems to work only subject a certain drawback. I'd like to confirm this drawback for an article I'm about to publish.

My understanding is that, in order for Jest Runner to work with a monorepo without making jest a dependency of each workspace, the following three conditions must hold:

• The monorepo root must declare jest as a dependency.
• The extension settings must hardcode the absolute path to the monorepo root installation of jest.
• VSCode must be in workspace mode using a .code-workspace file.

Jest will successfully pick up a jest configuration that is local to a workspace, as desired.

However, I'm encountering this drawback: When opening VSCode in workspace mode, VSCode requires that jestPath be stored in the .code-workspace file. This file otherwise tells VSCode how to organize the monorepo into workspaces. It should be checked in to git so that other people do not have to create this often-large file in order to use the VSCode workspace feature. However, checking it into git places each person's absolute path into the repo, changing it on every git push and forcing each person to revise it after each git pull.

Is this drawback accurate, or does Jest Runner have additional tricks for me?

The Jest extension does not have this problem, and it doesn't not require me to tell it where to find Jest. (But I do prefer Jest Runner.) I do wonder why Jest Runner isn't just using the node dependency resolution algorithm to find the nearest installation of jest to run.

NOTE: I previously described a problem with not finding a package when using Jest Runner with central dependencies, but I've since determined that command line tests and the Jest extension were both pulling in a package that they should not have. Jest Runner was correctly bombing. I've corrected that problem.

[firsttris]

Most monorepos e.g. NX or nextjs use single version policy. Means all dependencies are in root.

There were multiple attempts from people to find the nearest jest binary. BUT this always broke something for someone else.

Jest-runner has alot of config options, simply because there are so many different project configurations.

At the end you don't need a workspace and you also don't need to hardcore anything. At least I have never done that. But again depending on your config you do.

[jtlapp]

Thanks for responding. My situation is that when centralizing all dependencies, I've been able to run tests from the command line and from the vanilla Jest extension but not from Jest Runner, unless I hardcode the path to jest.js. That's only solution I've found, so that's what I plan to document, unless you can help me find another way.

I'm documenting a workspace solution because I have multiple applications and libraries, I'm using Turborepo, and I'll be needing to publish some of the libraries to NPM.

I've a made this branch available, should you have time to investigate. It uses pnpm.

[jtlapp]

This has been quite a time-consuming endeavor, but I finally figured out how to get it working:

  "jestrunner.jestCommand": "npx jest"

The vanilla Jest extension reports failures to find jest.js when I load the project, but then it readily runs every test. Strange.

Thanks for enduring my struggle.