feat(coverage): v8 to track node:child_process and node:worker_threads contexts#9976
Conversation
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
88a5c08 to
fa35cd5
Compare
@vitest/browser
@vitest/browser-playwright
@vitest/browser-preview
@vitest/browser-webdriverio
@vitest/coverage-istanbul
@vitest/coverage-v8
@vitest/expect
@vitest/mocker
@vitest/pretty-format
@vitest/runner
@vitest/snapshot
@vitest/spy
@vitest/ui
@vitest/utils
vitest
@vitest/web-worker
commit: |
fef5aec to
188a95f
Compare
70f7641 to
3d1dce2
Compare
ed25468 to
66e52a1
Compare
fb7116a to
c0a7985
Compare
| import { loadProvider } from './load-provider' | ||
|
|
||
| const session = new inspector.Session() | ||
| let session: inspector.Session | null = null |
There was a problem hiding this comment.
This used to create unused new Session() on main thread too, oops.
b97e821 to
63acca7
Compare
63acca7 to
92ab430
Compare
|
|
||
| Collect coverage only for files changed since a specified commit or branch. When set to `true`, it uses staged and unstaged changes. | ||
|
|
||
| ## coverage.trackProcessAndWorker |
There was a problem hiding this comment.
Naming this option is difficult. Right now it only covers node:child_process and node:worker_threads, but in future it's likely going to be used for web workers and similar on browser. @hi-ogawa & @sheremet-va - please propose better name here. 🙏
Internally this feature also uses term extendedContextCoverage. 🙃
There was a problem hiding this comment.
I don't think worker really fits in here, both child process and a worker thread is a worker in my opinion, at least that's how we defined it for pools, maybe trackProcessAndThreads is more accurate.
I would vote for something like includeSubprocesses/instrumentSubprocesses - subprocess can refer to anything, not just a fork/thread/service worker
There was a problem hiding this comment.
In debugging world there is also --follow-forks mode (in C), in vscode it's autoAttachChildProcesses (although it also follows workers)
There was a problem hiding this comment.
How about autoAttachChildContext? Or autoAttachWorkers and imply Worker is processes too. 🤔
There was a problem hiding this comment.
I feel like the common denominator here is subprocess, I wouldn't call any subprocess a worker, but every worker a subprocess
There was a problem hiding this comment.
It's not a process in a sense of node:child_process, but it is a process in a general sense
There was a problem hiding this comment.
No, it's not a process even in a general sense.
There was a problem hiding this comment.
Well, process is not a worker in a general sense
There was a problem hiding this comment.
Worker is already taken and it would be confusing to reuse the word within the Vitest repository. Subprocess to me sounds like the most general way to describe anything spawned by the user code
There was a problem hiding this comment.
Worker is not a term that's used in general sense 🙃. But sure let's think in NodeJS context.
Ok, let's use autoAttachSubprocess. I don't care that much.
92ab430 to
c1073e1
Compare
c1073e1 to
2eb5e8d
Compare
|
Awesome! |
Description
@vitest/web-workererror when using browser environment #4899Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
pnpm-lock.yamlunless you introduce a new test example.Tests
pnpm test:ci.Documentation
pnpm run docscommand.Changesets
feat:,fix:,perf:,docs:, orchore:.