fix(jest-core): always use workers in watch mode #14059
Conversation
The comment here already said one good reason to do this; another is that if the test hard-crashes (e.g. an async error after it completes) then using workers allows us to still watch for changes (perhaps to fix that crash). So now we just always use workers in watch mode; this probably worsens startup time slightly but for watch mode that's hopefully not as much of a problem. Fixes jestjs#13996.
| * watchAll. | ||
| * If we are using watch/watchAll mode, don't schedule anything in the main | ||
| * thread to keep the TTY responsive and to keep the watcher running even if | ||
| * the test crashes. |
There was a problem hiding this comment.
Hm.. Perhaps the comment should say: "and prevents watch mode crashes caused by tests leaking due to improper teardown". Or something that way?
It isn’t that workers do prevent watch mode to crash due to fatal errors in tests, that is more about preventing leaks / open handles or debugging them (as you pointed out in the issue).
There is no mechanism to deal with this problem if tests run in band. Leaks are handled more gracefully in parallel run, because worker farm gets killed after tests run is finished:
There was a problem hiding this comment.
Thanks for the suggestions -- took another stab at explaining this.
| const isWatchMode = watch || watchAll; | ||
| if (isWatchMode) { |
There was a problem hiding this comment.
| const isWatchMode = watch || watchAll; | |
| if (isWatchMode) { | |
| if (watch || watchAll) { |
| * Finally, the user can provide the runInBand argument in the CLI to | ||
| * force running in band. | ||
| * https://github.com/facebook/jest/blob/700e0dadb85f5dc8ff5dac6c7e98956690049734/packages/jest-config/src/getMaxWorkers.js#L14-L17 |
There was a problem hiding this comment.
Leave this comment in place, please. Check that link, the logic there sets maxWorkers to 1 if runInBand is provided. At first it is not clear why runInBand is mentioned here, but it makes sense. Or?
There was a problem hiding this comment.
Ah, you're right, thanks. (It seems with the workerIdleMemoryLimit check that is no longer quite right -- we should pass runInBand in here or more likely reject setting the two together -- but that's probably best left to another PR.)
There was a problem hiding this comment.
workerIdleMemoryLimit is a special case. It works only if workers are involved. (Feel free to add a comment.) There is no other mechanism to force workers. By the way, workerIdleMemoryLimit could be used to force workers in watch mode ;D
Summary
The comment here already said one good reason to do this; another is that if the test hard-crashes (e.g. an async error after it completes) then using workers allows us to still watch for changes (perhaps to fix that crash). So now we just always use workers in watch mode; this probably worsens startup time slightly but for watch mode that's hopefully not as much of a problem.
Fixes #13996.
Test plan
Updated existing unit tests. Let me know if it makes sense to add something e2e for the specific crash case in #13996.