Clear resolved modules cache before runJest in watch mode #8650
Conversation
Connormiha
force-pushed
the
fix-strong-cache-in-watch-mode
branch
2 times, most recently
from
debd2a8
to
1aabd98
Compare
|
It seems like a good place to clear it, yeah. Do you have a repro for a bug with this so that we can check that it is fixed? |
|
I did not see a special issue. I have only comment with this bug after merge my previus PR. |
|
Ah okay, thanks a lot for following up to ensure quality here! :) Go ahead then, would be cool to have a test that simulates a change in what a file resolves to in order to test the cache invalidation, I don't think we have something like this yet 😅 |
Connormiha
force-pushed
the
fix-strong-cache-in-watch-mode
branch
2 times, most recently
from
2f5380a
to
f404fbd
Compare
There was a problem hiding this comment.
Thanks for following up @Connormiha!
I left a comment on how I imagine the test could be more realistic, do you think that could work? The test is still fine if it doesn't work out, this is just something I thought about writing the last comment that would be a cool way of testing this cache invalidation.
packages/jest-resolve/src/index.ts
Outdated
| @@ -79,6 +79,10 @@ class Resolver { | |||
| this._modulePathCache = new Map(); | |||
| } | |||
|
|
|||
| static clearCache() { | |||
There was a problem hiding this comment.
Since this only clears the cache of the default resolver, should the name change to reflect that?
Potentially, add the property to the resolver itself, and check of resolver.clearCache or something exists?
Connormiha
force-pushed
the
fix-strong-cache-in-watch-mode
branch
from
f404fbd
to
5192931
Compare
|
@jeysal i added real test. |
Connormiha
force-pushed
the
fix-strong-cache-in-watch-mode
branch
from
5192931
to
461b527
Compare
There was a problem hiding this comment.
@Connormiha This is absolutely amazing, thanks for all the effort you put into it. Testing watch mode reruns with so little is very impressive and I think the test could be a very good example for similar things in the future.
Any clue what might cause the test to fail on Windows? Probably fs-related but I can't find anything problematic in the test.
Connormiha
force-pushed
the
fix-strong-cache-in-watch-mode
branch
from
f11847a
to
1d93984
Compare
Connormiha
force-pushed
the
fix-strong-cache-in-watch-mode
branch
from
1d93984
to
b5f09eb
Compare
| }, | ||
| ); | ||
|
|
||
| const config = normalize( |
There was a problem hiding this comment.
any reason not to use createGlobalConfig and createProjectConfig from TestUtils.ts in root here? Instead of normalize
There was a problem hiding this comment.
makeGlobalConfig from TestUtils.ts doesn't use normalizer inside. Without it this test will not work correct.
| watchman: false, | ||
| }); | ||
|
|
||
| const realContext = await hasteMapInstance.build().then(hasteMap => ({ |
There was a problem hiding this comment.
I need both variables hasteMapInstance and realContext.
There was a problem hiding this comment.
const hasteMap = await hasteMapInstance.build();
const realContext = {
config,
hasteFS: hasteMap.hasteFS,
moduleMap: hasteMap.moduleMap,
resolver: Runtime.createResolver(config, hasteMap.moduleMap),
};?
There was a problem hiding this comment.
hasteMapInstance should be passed in watch. Build doens't return instance.
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
This patch fixes bug with
watchAllmode.#8388 (comment)
My solution:
I just clear
checkedPathsbefore repeated run in watch mode to avoid situation when we have legacy path information.Test plan
I added test to avoid this bug in a future.