Detection for accidentalStrictMode results in failures on some platforms

[krhougs]

Some Javascript runtime like Wechat MiniProgram and Alipay MiniProgram forbids dynamically defining function (related documents), where both Function and eval are undefined.

Recently added detection for accidentalStrictMode used Function as a rescue, which results in failures.

Is there better way to detect accidentalStrictMode or just bypass it?

[aztack]

Cocos Creator also has forbidden Function and eval. Introducing regenerator runtime into a Cocos Creator project enables using await/async but prevents projects to be published to the Cocos Play platform.

[shcarrico]

I am having this same problem; using strict CSP with no unsafe-eval, i end up in the catch block for some reason. I am not entirely clear what is causing me to be in "accidentalStrictMode". Am using the react toolchain based on create-react-app. Am attempting to downgrade this for the time being...

[rbrewington]

I'm having this problem also. I'm working on a healthcare app and allowing unsafe-eval in the CSP is not an option. I can disable strict mode in the rollup options of my library but this seems like a bad workaround. I feel like strict mode should be able to work, and we shouldn't have to give up the performance optimizations and error detection benefits.

[AndrewCraswell]

I think this needs to be revisited. I'm also using toolchains such as create-react-app and tsdx and seeing failures. Both projects are closing issues related to this because they argue it's the problem of regenerator-runtime. Unfortunately our project will fail compliance without a strict CSP, and I'm not sure how to disable strict mode from create-react-app. And as Mozilla noted in regards to this issue, disabling strict mode isn't something anyone is keen to do.

I thought I could resolve the issue by using a yarn resolution to force an older version that doesn't exhibit this issue, but unfortunately that doesn't work either because multiple other libraries we depend on come pre-bundled with a later version of regenerator-runtime. Seems like the only way we will be able to get CSP working is if an update resolves the issue, and libraries start taking in the update. :/

[benjamn]

I recently became aware of a very clever globalThis polyfill that works in all JS implementations, without ever resorting to using the Function constructor: https://mathiasbynens.be/notes/globalthis (by @mathiasbynens).

Here's another project where I implemented this polyfill, and it's worked perfectly so far: https://github.com/apollographql/invariant-packages/pull/53

For historical reasons, I've tried to keep regenerator-runtime/runtime.js runnable as a single script (rather than a CommonJS or ESM module), so I think we would need to inline the https://www.npmjs.com/package/@ungap/global-this implementation, rather than importing it, but it's very short.

Any objections to moving forward with that approach?

[Jack-Works]

For anyone who struggled with this problem: Run this code before regenerator-runtime executes

globalThis.regeneratorRuntime = undefined

[bwindels]

Also hitting this because of the CSP header not allowing unsafe-eval. The globalThis approach indeed seems more practical than disabling strict mode for your entire bundle, which is not the default and thus hard to discover what the actual problem is. It also might make the code run slower by preventing optimizations.

Thanks for providing this great piece of javascript infrastructure in any case!

[mikecann]

I too am struggling with this issue when building for a chrome extension using esbuild.

Has anyone got a workaround this?

[Jack-Works]

Yes, @mikecann

You can run this code:

globalThis.regeneratorRuntime = undefined

Before regenerator is loaded.

[mikecann]

@Jack-Works ye I ended up doing something simmilar thanks to evanw's help: https://github.com/evanw/esbuild/issues/1006#issuecomment-802611119

[almilo]

+1

[Ky6uk]

Does it progress somehow? I've spent tons of time while found this issue because the bug had appeared only on production deployment with strict CSP rules. And still have no idea how to fix it.

I've tried to add an intro banner with window.regeneratorRuntime = undefined (using Vite build tool) and the problem with accidentalStrictMode has gone, but another problem has appeared — third party library is using method regeneratorRuntime.mark(). So mark of undefined is another headache.

[Jack-Works]

The trick I mentioned only used to define the global variable and the instantiation of the object should be done by the regenerator-runtime. If any of your code runs before the regenerator-runtime I think it's a bundle error

[Ky6uk]

Yeah, I'm working to find the problem entry point at the moment. Just mentioned accidentalStrictMode failure is super unintuitive and hard to detect the problem as many conditions should be passed at the same time. 😞

[ValerioSevilla]

Found this issue while trying to load ExcelJS from Salesforce. I have mentioned it in this ExcelJS issue. It seems there is no official solution yet?

[yoyo930021]

Fix in https://github.com/facebook/regenerator/issues/450 ?

[wjpg]

Fix in #450 ?

We still needed to set globalThis.regeneratorRuntime = undefined even with the updates in #450