Fix EvalError caused by regenerator-runtime (#4535)

[snoack]

Description of the Change

Mocha provides a bundle that can be used directly in the browser. For compatibility with Internet Explorer 11, the bundled code is transpiled using Babel. When using async functions (or generator functions) as Mocha started in 12db9db (8.2.0), Babel adds the regenerator-runtime module to the bundle, which relies on unsafe eval to access the global scope in strict mode, which in turn makes Mocha incompatible with environments that don't allow unsafe eval.

In this PR, I implement a workaround that prevents regenerator-runtime from using unsafe eval. First I had to update regenerator-runtime since the currently used version relies on this in an unbound function referring to the global object which we don't have any control over, while the new version instead exploits implicit global assignments:

try {
  regeneratorRuntime = runtime;
} catch (accidentalStrictMode) {
  // This module should not be running in strict mode, so the above
  // assignment should always work unless something is misconfigured. Just
  // in case runtime.js accidentally runs in strict mode, we can escape
  // strict mode using a global Function call. This could conceivably fail
  // if a Content Security Policy forbids using Function, but in that case
  // the proper solution is to fix the accidental strict mode problem. If
  // you've misconfigured your bundler to force strict mode and applied a
  // CSP to forbid Function, and you're not willing to fix either of those
  // problems, please detail your unique predicament in a GitHub issue.
  Function("r", "regeneratorRuntime = r")(runtime);
}

While this isn't working either in strict mode without unsafe eval, it allows us to work around the issue by declaring the regeneratorRuntime variable before this code is reached (done here via Rollup's output.intro setting). That way regeneratorRuntime = runtime is no longer an implicit definition of a global variable (which fails in strict mode), but it becomes a simple reassignment of an existing variable, and so the code in the catch block (which requires unsafe eval) is never reached.

Alternate Designs

1. If it wouldn't be for Internet Explorer 11, we wouldn't need to transpile the code in the first place, and this issue wouldn't exist. There is also the option to tell Babel to just not use transform-regenerator in which case the transpiled code would at least remain compatible with legacy browsers that support generator functions but might lack other modern ES features.
2. Refactoring the code to not use async/await.
3. Providing two bundles, one with transpiled code that works in IE11 (but will require unsafe eval), and one that isn't transpiled.

Alternative 1 and 2 were ruled out by @juergba in the discussion in #4535. Alternative 3 seems somewhat more complicated than the workaround I ended up implementing here, and it would require users to choose the correct bundle for their environment.

Why should this be in core?

Because it fixes a regression introduced in Mocha 3.2.0.

Benefits

Mocha can be used once again in environments where unsafe eval is not allowed. This includes browser extensions, as well as websites with restrictive Content-Security-Policy.

[juergba]

@snoack thanks for this PR!

The browser tests never work on PR's from forked repos. This is a problem of secrets (saucelabs login info) not being shared with forked repos. I'm going to push your branch to Mocha's repo directly.

Edit: browser tests are passing now.

[juergba]

@Munter I need your review for this PR, please.

[juergba]

@snoack have you tested this new bundle in your environment?

[snoack]

Yes, I did. Works.

[juergba]

@snoack thank you!
Please be patient for some days, I will wait for more reviews.

[juergba]

Babel seems to struggle a bit with publishing, see Babel v7.12.18.
v7.12.18 is not available yet on npm.

[juergba]

@snoack I'm going to merge this branch tomorrow.

Babel is publishing new releases every few hours, some kind of weird. I don't think we need to upgrade to the newest one, what do you think?

[snoack]

Sounds good.