-
-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Monorepo instructions are unclear, samples not working #81
Comments
I'm getting the same errors in my own mono repo when using the extension. I can see the tests, but not run them (get the same "Test result not found" message). I'm also on macOS using M1 processor. Trying to debug with a launch.json file and setting the program folder to the correct node_modules folder with vitest.mjc in it and launching the test file in debug mode also doesn't work and prompts me to install vite because it is not installed.
I am aware that doesn't directly relate to the extension, but it might be useful info? |
Same problem here also with a monorepo setup (using Gitpod, but shouldn't matter). I also get the error message "Test result not found.". Any workarounds yet? |
Having the same issue :/ |
I have the same issue with the latest release including the fix for #55. I'm not clear what the correct
and each package is:
This means multiple vitest processes. Is there a different way to setup vitest so it is one process over the entire monorepo that would then work with this vscode plugin? |
Sorry to bother you @zxch3n but, any workaround for this monorepo issue? Or can u provide some information about this, im glad to create a pr if i can :) |
Here's my scenario and workaround. I have a monorepo that, so far, only uses Vitest in one of the projects. I configured this extension to run the tests as follows:
|
I've also been struggling to run my tests which, together, with
or (more or less equivalently)
where the
Anyway, in both cases vitest then still reports "Test result not found […]" for every single test, even though the verbose test logs do report the test results, e.g.:
What gives? |
I'm able to get some integration working with this with a monorepo but not quite. In my root
And then in my VSCode configuration:
But I'm getting that all of the tests are skipped:
Here's what Vitest runs according to Visual Studio:
|
@zxch3n could you or someone else from the team please have a look? Since there are examples for monorepos, and you created those, I think you are probably the most suitable person to answer the questions in this issue. |
Same here. I have debugged it and found some information. First, I have two test files in the single and multi repo. single // samples/basic/test/add.test.ts
import { describe, expect, it } from 'vitest'
describe('single testing', () => {
it('1', () => {
expect(1).toBe(1)
})
it('2', () => {
expect(2).toBe(2)
})
}) multi // samples/monorepo/packages/react/test/basic.test.tsx
import { describe, expect, it } from 'vitest'
describe('multi testing', () => {
it('1', () => {
expect(1).toBe(1)
})
it('2', () => {
expect(2).toBe(2)
})
}) There was some difference between them when I added the breakpoint in the handler event.
I don't know why the So the And I found another problem in the // ✅
npm vitest // ✅
npm vitest Is that mean I must run this command( vitest ) in the sub-package directory, or have I lost some arguments? This repo's underlying logic is run the command line in the node, so maybe this problem causes this issue. @zxch3n |
Would be very nice to have a similar guide on how to use the extension that Jest extension has - with images and examples. |
I finally found a proper workaround for something that should definitely be integrated into the plugin itself. Create file import fs from "fs";
import path from "path";
import { execSync } from "child_process";
const [testFile, ...args] = process.argv.slice(2);
const findClosestPackage = (p) => {
const parent = path.dirname(p);
if (fs.existsSync(path.join(parent, "package.json"))) return parent;
return findClosestPackage(parent);
}
const cwd = findClosestPackage(testFile);
const targetPath = path.relative(cwd, testFile);
execSync(`pnpm vitest -w ${targetPath} ${args.map((a) => a.startsWith("-") ? a : `"${a}"`).join(" ")}`, { env: { ...process.env }, cwd, stdio: "inherit" }); And add this to your "vitest.commandLine": "node .vscode/vitest-fix.mjs", What it does? It consumes all passed args and then runs
|
Please, use the latest pre-release version.
The latest version doesn't support |
@sheremet-va Then lets hope the pre-release also fixes finally that issue with these workspaces, where I have to manually do things that could have been just inferred correctly by searching for the closest vite(st) config :/ |
There is no need to "hope", you can install it yourself and see if it fixes it for you. |
If I understand it correctly the extension has a hard-requirement that you install I think it would be nice if it would use the Also seems to display all workspaces (using |
There is no such requirement, it uses the working directory of a config file.
It only shows tests that Vitest found with provided config. |
We're also have trouble setting this up. I can provide a full reproduction if that would help? In short, we have:
The reason we have the nested Only the first app shows up (containing a If I do add a
Perhaps the issue for us is the that extension doesn't recognise non-workspace level I'm happy to help out with this issue too. |
Please, do. The extension prioritizes workspace configs, and should always start a separate Vitest process for every config. It will ignore non-workspace Vitest configs if there is at least one workspace config. |
Hi @sheremet-va, I think that's the issue we're hitting.
Here's a minimal repro, showing how we have this set up: |
Then, it is expected. The extension priorities are:
If the extension finds one, it ignores the others. |
What changes could we make to this to support the extension better? We don't really want to have a repo-root Perhaps the extension could differentiate between "projects" and "workspace", where I'm happy to contribute to Vitest to help improve this. |
I don't know what would be the best way to do that, honestly. Technically, we can initiate all workspaces first, then glob all config files and filter out those that are part of the workspace, maybe? And the rest can be initiated as separate processes. It's quite hard to "guess" what the user expectation is based on the file system structure. I am open to any ideas (just in a sentence form is fine, not necessarily an implementation). The recommended way right now is to have a single |
From my perspective, it feels like the Your idea seems like it would work, and be a simple, non-breaking change. Another approach might be to make a breaking change:
In that case, the extension could prioritise |
The thing is that we don't want to encourage people to have a lot of configs in separate places. There is even a warning if you have more than three configs. Allowing mixing workspaces and configs contradicts this. The extension spawns a new process for every config and keeps it running in the background to achieve very fast feedback when you press the "run test" button. Keeping a lot of processes is not very memory and CPU efficient, so I would rather focus on improving the single |
My team could use the approach you've used above ( I do understand the performance concern though. A monorepo could theoretically have multiple version of Vitest in use, which could add to the confusion. Perhaps the extension could be changed to only keep alive processes for files that are open? |
This might actually be relatively easy to implement, but we will still need to start the process and close it at least once to get all test files (Vitest is the one resolving all the configs and workspaces, not the extension). |
Describe the bug
Currently, there is (some) support for monorepos, but how to actually get extension working for monorepos is unclear.
The monorepo examples in
/samples
don't work out of the box as well.To Reproduce
Steps to reproduce the behavior on the example project:
samples/monorepo
in vscodeExpected behavior
The tests should run successfully.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
(Paste info.txt content generated by the example project)
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: