Support node_modules being in a different directory than {WorkspaceFolder}/ about vscode-jest-runner

[MetaSam]

We have the same issue. I tried to set the "config path" and "jest path" options but it is not sufficient. I believe a "root path" configuration would be needed.

[firsttris]

in version 0.4.24 you can define a fixed project path from where jest & config is used.

please re-open if this does not solve you problem.

[firsttris]

Hey @mclean25

don't get me wrong, i just tell you what my experience is.

i would say your project setup is a bit unusual.

seems that your team have structured his project like a mono-repo, without setting it up like a mono repo.

generally you would choose between the following options:

• use vscode workspaces feature (to open multiple projects within vscode). then everything would work like you described it e.g. "cd webApp && npm test". because my addon would know you are using multiple projects.

• use yarn worksapces. which would bascially install identical dependencies between your project to root/node_module. means jest would not be installed to root/projectN/node_modules/jest instead to root/node_module/jest

my addon works with both solutions, because their the most common once.

but if you just have a couple of folders, how should my addon know that those are projects?

if you have a clean approach how to implement this, im happy to consider it.
(there were in total like 3-4 people requesting this. )

but isn't the question where really the issue is? project-setup?

i mean features like this could easily lead other teams with correct project-setup into errors.

let me know what you think.

regards
Tristan

[mclean25]

Those both make sense to me, but unfortunately I don't think either will work for our scenario.

Our setup is something like this:

${workspaceFolder}
| - /.git
| - ./old-app (django web-app)
| - ./new-app (react app)

Workspace folders doesn't quite work I think, because our project isn't quite multi root, as we still need a bunch of the shared resources in /${workspaceFolder}. Yarn work-spaces might be an option, but we really only need JS packages in ./new-app.

As for an idea to the solution. I was thinking maybe a post run command would suffice, so you could do cd new-app && npm run test for the custom command and then cd ../ for the post command. It's a little hacky. Another option could maybe be a "woking dir" setting where something like ./new-app would be provided, and then Jest Runner would know to cd in/out before/after doing it's thing. Don't really like either of these 100%, and I do see your point that our monorepo setup isn't quite ideal.

[firsttris]

another idea

option 3.)
create a symlink from multiroot/new-app/node_modules/jest/bin/jest.js to multiroot/node_modules/jest/bin/jest.js

option 4.)
use jestrunner.jestPath and set to fullpath/new-app/node_modules/jest/bin/jest.js
(would also be an option to install jest globally and set jestPath to fullGlobalPath/node_modules/jest/bin/jest.js)

let me know if one of these options work!

regards
Tristan

[Ranguna]

This is not unusual at all. Anyone who uses firebase functions will have this type of file structure.

firebase init will scaffold something like this:

rootFolder
| - .firebaserc
| - firebase.json
| - functions
    | - node_modules
    | - package.json
    | - src
        | - index.js

This extension will execute jest in rootFolder instead of the functions folder.

I don't like this file structure more than anyone else and I would love to change this but it's a little out of my hands. So it'd awesome if we could have a setting to define the project root folder, something like jestRunner.projectPath.

In my case jestRunner.projectPath would be ${workFolder}/functions

EDIT:
Maybe #84 would help.

[Ranguna]

A side not that I posted in #84:
This will not work when users use predefined variables such as ${workspaceFolder}, because vscode extension API does not replace variables when extensions read from settings. There are two open issues in vscode: microsoft/vscode#2809 and microsoft/vscode#46471 .