chore(js): update jest to v24; drop --runInBand

[IanLondon]

overview

make test-js is taking ~16.5 minutes on Travis. This is causing some builds to time out and fail. There's a forceful workaround: adding using the travis_wait util to run this step via travis_wait make test-js in .travis.yml will allow the build to not time out.

On my machine, it takes ~1.5 minutes real using yarn jest --runInBand --coverage. But, unlike Travis, I have a jest cache built up locally from running this before. When I add --no-cache and do yarn jest --runInBand --coverage --no-cache, it takes ~10 minutes. It seems like Running coverage on untested files... accounts for the bulk of that difference. And without --coverage, running yarn jest --runInBand --no-cache takes ~1.25 mins. Also, yarn jest --coverage --no-cache (parallelization enabled, no cache) takes only ~1 minute!

In summary: coverage without parallelization is very slow and is only performant if you have a jest cache already built up. So the options are

1. Enable parallelization (may cause nondeterministic flaky failures in Travis sometimes, that's why we added --runInBand see Flaky failure mode when running tests jestjs/jest#1874 )

• Try bumping Jest version to 24 and hope the flakiness is fixed

2. Enable jest caching on Travis
3. Disable or restrict coverage (even though we seldom use it, seems like a bad idea to turn it off/down!)
4. Use travis_wait for the make test-js step so Travis doesn't time out. I confirmed that this works on a test branch build. But feels like a band-aid, the make test-js step will still take ~16.5 min this way

This PR takes option 1!

changelog

• upgrade jest
• remove --runInBand

review requests

For additional context, see #2815 and jestjs/jest#1874

1. make install-js to install the new jest
2. make test-js should pass on your machine
3. Travis builds should pass and not time out!

[b-cooper]

🚤

[IanLondon]

Wow FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory https://travis-ci.org/Opentrons/opentrons/jobs/553813705#L848

[codecov]

Codecov Report

Merging #3672 into edge will increase coverage by 5.54%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             edge    #3672      +/-   ##
==========================================
+ Coverage   28.84%   34.38%   +5.54%     
==========================================
  Files         733      714      -19     
  Lines       13313    11173    -2140     
==========================================
+ Hits         3840     3842       +2     
+ Misses       9473     7331    -2142

Impacted Files	Coverage Δ
components/src/tooltips/HoverTooltip.js	11.76% <0%> (-1.57%)	⬇️
components/src/forms/SelectField.js	13.63% <0%> (-1.37%)	⬇️
...onents/src/interaction-enhancers/HandleKeypress.js	6.66% <0%> (-1.03%)	⬇️
components/src/deck/Deck.js	7.69% <0%> (-0.31%)	⬇️
...omponents/DeckSetup/LabwareOverlays/LabwareName.js	0% <0%> (ø)	⬆️
protocol-designer/src/analytics/actions.js	0% <0%> (ø)	⬆️
...designer/src/components/FileSidebar/FileSidebar.js	0% <0%> (ø)	⬆️
...onents/analytics-settings/AnalyticsSettingsCard.js	0% <0%> (ø)	⬆️
...p/src/components/TipProbe/InstrumentMovingPanel.js	0% <0%> (ø)	⬆️
app/src/components/MenuPanel/index.js	0% <0%> (ø)	⬆️
... and 391 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ea9fb82...ca5652c. Read the comment docs.

[mcous]

With #3683 we should see if this cache removal is really necessary. On my Ubuntu VM (2 cores, 4GB memory) I'm seeing:

• No cache: ~110 seconds
• Cache enabled, cold: ~110 seconds
• Cache enabled, subsequent run: ~75 seconds
• No cache, 2 workers: ~220 seconds
• Cache enabled, cold, 2 workers: ~85 seconds
• Cache enabled, subsequent run, 2 workers: ~60 seconds

Given the speedup from caching (understanding that the numbers above are unscientific), I think Travis caching of the jest cache is definitely worth exploring in this PR or a followup

[IanLondon]

One downside is that on Travis, you have to spend time downloading the cache. My local jest cache for the monorepo is 143.5MB, but I'm not sure what that size might be contingent upon

[mcous]

CI is green and make test-js CI=true worked in my testing on macOS, Ubuntu 18.04, and Windows 10. We should see how this shakes out this week and then ping the Jest folks to let them know if the flakiness without --run-in-band is (or isn't) fixed

🚢