NextFederationPlugin (8.1.7) builds require 'unsafe-eval' in Content Security Policy script-src

[arik-mesh]

Describe the bug

Statically serving next apps builds using version 8 of NextFederationPlugin give errors when 'unsafe-eval' is an allowed script-src.
This is new in version 8 (worked fine in 7)

Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' www.googletagmanager.com www.google-analytics.com tagmanager.google.com static.zdassets.com ekr.zdassets.com meshpaymentshelp.zendesk.com connect.facebook.net maps.googleapis.com cdn.plaid.com *.hotjar.com *.hotjar.io *.auth0.com www.googleadservices.com *.segment.com *.segment.io *.appcues.com *.appcues.net bat.bing.com snap.licdn.com cdn.merge.dev https://api.smooch.io https://cdn.icomoon.io".

    at new Function (<anonymous>)
    at 1026 (share.esm.js:91:22)
    at __webpack_require__ (bootstrap:24:23)
    at 9083 (index.cjs.js:3:15)
    at __webpack_require__ (bootstrap:24:23)
    at 6093 (main-2296636e816d6003.js:1:111)
    at __webpack_require__ (bootstrap:24:23)
    at main-2296636e816d6003.js:1:193475
    at r (jsonp chunk loading:75:28)
    at main-2296636e816d6003.js:1:51

Live example

Reproduction

https://github.com/arik-mesh/next-mf-7-vs-8

Used Package Manager

npm

System Info

System:
    OS: macOS 14.2.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 25.52 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.19.0 - ~/.nvm/versions/node/v18.19.0/bin/node
    npm: 10.2.3 - ~/.nvm/versions/node/v18.19.0/bin/npm
    pnpm: 8.10.2 - /opt/homebrew/bin/pnpm
  Browsers:
    Chrome: 120.0.6099.234
    Edge: 120.0.2210.144
    Safari: 17.2.1

Validations

• Read the docs.
• Read the common issues list.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Module federation issue and not a framework-specific issue.
• The provided reproduction is a minimal reproducible example of the bug.

[ScriptedAlchemy]

I can do something like this:

function returnGlobal() {
  try {
    return new Function('return this');
  } catch {
    return globalThis
  }
}

The problem new Function solves is webpack can transform global references into __webpack_require__.g if user has global set in webpack then our "true" global reference will be replaced during compilation. So I must retain new Function however I can catch it and attempt to return the global var, assuming your build does not mess with it in envionment.global

[owlyowl]

I can do something like this:

function returnGlobal() {
  try {
    return new Function('return this');
  } catch {
    return globalThis
  }
}

The problem new Function solves is webpack can transform global references into __webpack_require__.g if user has global set in webpack then our "true" global reference will be replaced during compilation. So I must retain new Function however I can catch it and attempt to return the global var, assuming your build does not mess with it in envionment.global

Hi @ScriptedAlchemy (Zack)
I found your post here and sorry to Hijack but I'm having an issue with the npm es-abstract referencing globalThis adding new Function into my compiled output. I was wondering if there's a way to manipulate the webpack output to ensure it won't include globalThis in this way and cause csps to blow up on unsafe eval.. I thought given your exposure to this you might have a suggestion?

[ScriptedAlchemy]

Yeah. Environment.global. set it to false. Might be output.envionment.global can't remember. This will make webpack not use require.g