|
4 | 4 | import * as path from 'path';
|
5 | 5 | import { Import, FileSystem } from '@rushstack/node-core-library';
|
6 | 6 |
|
7 |
| -// This patch is a fix for a problem where Jest fails to rename the cache file on a machine that is under heavy load: |
8 |
| -// |
9 |
| -// "failed to cache transform results in: <jestCachePath>/jest-transform-cache-*/... |
10 |
| -// Failure message: EPERM: operation not permitted, rename |
11 |
| -// '<jestCachePath/jest-transform-cache-*/...' -> '<jestCachePath>/jest-transform-cache-*/...'" |
12 |
| -// |
13 |
| -// The upstream issue is here: https://github.com/facebook/jest/issues/4444 |
14 |
| -// |
15 |
| -// The relevant code is in jest-transform/src/ScriptTransformer.ts: |
16 |
| -// https://github.com/facebook/jest/blob/835a93666a69202de2a0429cd5445cb5f56d2cea/packages/jest-transform/src/ScriptTransformer.ts#L932 |
17 |
| -// |
18 |
| -// The problem is that Jest encounters a race condition on Windows where the cache file has already been renamed by |
19 |
| -// another worker process. This only occurs because Windows does not support atomic writes, which are used on other |
20 |
| -// platforms. The fix is to wait for the rename to complete, instead of failing if the renamed file isn't immediately |
21 |
| -// available. |
| 7 | +// This patch is to disable cache reads/writes in Jest. Cache reads/writes add a lot of overhead I/O to Jest, |
| 8 | +// which can especially impact Windows executions. In addition, cache interaction has lead to some issues with |
| 9 | +// Jest in the past, such as a race condition when attempting to rename the target cache file (see: |
| 10 | +// https://github.com/facebook/jest/issues/4444). Passing '--no-cache' to Jest simply tells Jest to not read |
| 11 | +// the produced cache files, but does nothing to prevent writing of these files. This patch disables both |
| 12 | +// reading and writing of cache files. |
22 | 13 |
|
23 | 14 | interface IScriptTransformerModule {
|
24 | 15 | createScriptTransformer: unknown;
|
|
0 commit comments