CSP that blocks unsafe eval errors on regenerator-runtime

Current Behavior

I’ve created a library which compiles and works fine. I can import it in my app and everything runs locally. When I deploy the app to a production environment, the app cannot load and gives an Uncaught EvalError

The app had no CSP issues prior to introducing tsdx (previously my library was bootstrapped by create-react-library)

Expected behavior

I can run an app with a library dependency bootstrapped by tsdx in an environment using a CSP

Suggested solution(s)

I’m not really sure how to fix it, but it seems like regenerator-runtime is running in strict mode but it’s not supposed to be? It looks like this might have been changed in later versions of regenerator-runtime, so maybe updating it would work?

here’s the block from regenerator-runtime that the CSP gets tripped up on (specifically the line in the catch block):

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);
}

Additional context

Here are some related(?) issues that were all I could really find when searching this https://github.com/facebook/regenerator/issues/336 https://github.com/babel/babel/issues/12106 https://github.com/indico/react-overridable/issues/2 mozilla/pdf.js#11036

Your environment

System:
    OS: macOS Mojave 10.14.6
    CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
    Memory: 201.23 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 14.15.1 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.8 - /usr/local/bin/npm
  Browsers:
    Safari: 14.0.2
  npmPackages:
    tsdx: ^0.14.1 => 0.14.1 
    typescript: ^3.7.5 => 3.9.7 
  npmGlobalPackages:
    typescript: 3.1.6

[AndrewCraswell]

I think this is where I’m getting stuck: https://github.com/formium/tsdx/issues/169

Is there a way to disable the auto injection of the regenerator-runtime? Seems this was included not too long ago. I generally prefer the consumer to be able to control which polyfills are bundled to avoid the duplication hell that causes these exact sort of pitfalls. Another approach I’ve seen is to include polyfills in the CJS bundle, but not in the ESM.

[rbrewington]

Thank you for the advice. Unfortunately I have to support IE11 and pinning the regenerator runtime also sounds like a potential security concern. I had tried the rollup config approach, but had the path to the strict option wrong. I’ll try that.

Hopefully the regenerator team can find a way to fix this. For anyone else experiencing this, I’m following this open issue to see if they do: https://github.com/facebook/regenerator/issues/378

ETA: Alas… the rollup configuration prevented ‘use strict’ from being added by my library, but the app that is using the library is built with CRA and I believe it added ‘use strict’ when I compiled the app. In any case, my app is still violating the secure CSP.

If anyone knows how to disable ‘use strict’ in CRA please let me know.