Support cwd of current package inside monorepo

[cdauth]

I am using this plugin in a monorepo with several modules. In my case, I have configured jestrunner.jestCommand to be yarn test (which in my case executes vitest instead of jest).

By default, vscode-jest-runner executes the command on the root level of my monorepo. I would like it to execute on the root level of the individual NPM package instead, for several reasons:

• I don't have jest (or in my case vitest) installed on the root level
• The implementation of my yarn test command might be different for each module

Since #156, the project path is automatically detected based on where a package.json file and a node_modules/.bin/jest file is present. In case of a monorepo, this will only result in my desired behaviour if the modules have different versions of jest installed. If they all have the same version, node_modules/.bin/jest will be available on the root level of the repo.

As a workaround, I currently have jestrunner.changeDirectoryToWorkspaceRoot set to false and manually cd into the appropriate directory in the jest terminal before running the tests.

One way this could be achieved would be to add a config option (such as jestrunner.changeDirectoryToPackageRoot) that cds to the nearest ancestor directory containing a package.json file before running a test.

On the other hand, I'm wondering whether this behaviour shouldn't be the default. The location detection for the eslint executable would stay the same as today, but the detection of the cwd would become independent of that and use the closest ancestor directory containing a package.json. Are there any setups that this would break?

[bryceg]

similar issue here with monorepo, its cwd is down in the root. An option to specify the directory through a configuration option so I can use something like a vscode variable reference would help.

[domsleee]

From jestRunnerConfig.ts when it resolves cwd(), it looks for the nearest package, but only if the package has node_modules/jest:

https://github.com/firsttris/vscode-jest-runner/blob/81b797c77eb23fbc5c07a8a953a57b15edf0685a/src/jestRunnerConfig.ts#L64-L74

So the current fallback logic for jestrunner.changeDirectoryToWorkspaceRoot is:

1. jestrunner.projectPath
2. (code snippet above) the nearest package.json with jest in it's node_modules folder
3. ${workspaceFolder}

Would it make sense to change (2) to find packages with either jest or vitest in it's node_modules?

[firsttris]

i forgot we already have such a logic.

it seems like if we also check for vitest it would solve the issue?

[cdauth]

Adding support for vitest might be nice, but it does not solve the problem that I describe here.

The problem described here is that dependency hoisting causes jest/vitest to be installed in a different location than where it should be used. For example, the directory layout might look like this:

/package.json
/node_modules/.bin/jest
/module1/package.json
/module2/package.json

jest is only listed as a dependency in /module1/package.json and /module2/package.json and test scripts are defined in those files. In /package.json, jest is not defined as a dependency and there is no test script. But vscode-jest-runner would run the tests in /.

If module1 and module2 would for some reason depend on different versions of jest, the directory layout would change into this:

/package.json
/module1/package.json
/module1/node_modules/.bin/jest
/module2/package.json
/module2/node_modules/.bin/jest

So vscode-jest-runner would now run the tests inside the respective module folders.

Personally I don't see a use case where in the first case (both modules using the same jest version) the tests should run on the root level of the project. So my recommendation would be to simply remove the check for node_modules/.bin/jest altogether and simply run the tests in the nearest directory that contains a package.json. But maybe there is some use case that I'm not aware of.

[digitalmaster]

This is my exact issue as well. Also, agree that it seems like this would work as the default. But would be happy with an option.