Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Extract watch mode #2362
This should make watch mode faster and removes some duplicated code from
More info #2324 (comment) I hope that this will also allow us to add more tests in the future.
Current coverage is 62.92% (diff: 21.46%)
@@ master #2362 diff @@ ========================================== Files 116 123 +7 Lines 4802 4826 +24 Methods 0 0 Messages 0 0 Branches 0 0 ========================================== + Hits 2990 3037 +47 + Misses 1812 1789 -23 Partials 0 0
This was referenced
Dec 20, 2016
With this change we don't store the haste map on disk before starting to run tests. This means if Jest would like to run tests in parallel, we need to persist the haste map or pass it through to the workers, otherwise new files that get added can't be run and will fail.
I spent some time running some benchmarks on passing data to and back from the worker, see https://gist.github.com/cpojer/488c85f2cf86cacc3f4cc378be3f68eb This version takes about 6s on my mbp and about 1.3s when only sending data to the worker only (like we'd do in Jest). This is still a lot of overhead. One issue with persisting the state is also that the watchman clocks aren't updated through the file watcher – this means that storing the haste map as is will result in a recrawl of the file system on the next startup. There are a number of ways to address this:
I'm inclined to go with the first solution and benchmarking it on our internal react-native codebase, which is relatively big, to see what the performance will look like. Either way, I need to find a way to write tests for this as it is easy to break. I'll push directly to this PR and merge it once done. @rogeliog nice work on making this all happen!
Ok I tested this and it works now. @rogeliog mind checking my code before I merge this?
Here is what this solves:
Without my last commit, even after creating the "HasteModule.js" file, the test would fail and be unable to locate the new haste module (haste is Facebook's module resolution system) because we don't persist the haste map to disk so when we read it in the worker thread, it is still missing. My change makes it so that in watch mode, the module map is always passed to the workers and it is only read from disk in the regular mode.
One thing I haven't had time to do is write tests. It would be good to create some tests with some of the env mocked, like a