In rare cases, loadPresetReact could get into a race with itself. In
these cases the first call would set presetReact and the second call
would exit early as a result. This would mean babelOptionsJSX would be
undefined and the transformation would fail.
Prior to this, if a user first loaded a React challenge and then
navigated to a JS challenge, they would see
TypeError: Cannot read property 'presets' of undefined
in the console and be unable to run tests or evaluate code until they
reloaded the page.
The interview prep section includes many challenges that require long
running calculations which can be mistaken for infinite loops. This
removes the loop protection from those challenges, while the tests are
being evaluated.
It keeps the protection for the preview, since it is easy to create
broken code while working on a challenge and that should not crash the
site.
Code like `var xs = []; while(true){ xs.push(1) }` can quickly run the
browser out of memory causing it to crash. These changes stop user loops
from running indefinitely so that common mistakes will no longer cause
the browser to crash.
Also, the user is informed if a long running loop is detected (js and
jsx challenges) during preview or testing. Before this there was no
protection for js challenges and no information was given to the
user if they had created such a loop.
Co-Authored-By: Tom <20648924+moT01@users.noreply.github.com>
Co-Authored-By: mrugesh <1884376+raisedadead@users.noreply.github.com>
Co-Authored-By: Randell Dawson <5313213+RandellDawson@users.noreply.github.com>
Certain challenges involve code that is not run until the user
interacts with the preview (typically via a click listener). This uses
consoleProxy to report those errors.
Error logging has been simplified, reducing the number of places errors
can be reported from.
Some of the redux-saga code has been renamed in an attempt to improve
clarity.
* fix(client): add cache-busting hashes to chunks
* fix: create cache-busting names for the workers
Prior to this PR the first webpack compilation gave the workers static
names. This can cause caching problems, so this PR adds hashes to
their names to invalidate the cache.
In order for Gatsby to find them, the names are added to the
config directory.