[REGRESSION] webpack-plugin generates different output for arm64 and x64 builds on Mac OS, breaking universal builds

[TheRealCuran]

Pre-flight checklist

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project uses.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version

7.2.0

Electron version

27.1.3

Operating system

macOS 14.1.1

Last known working Electron Forge version

7.1.0

Expected behavior

Uiversal builds can be generated with electron-forge make --arch=universal --target=dmg --platform=darwin and it is ensured, that the same JS output is used for both the arm64 and the x64 build.

Since the same Electron version is used in both cases, there shouldn't be a need for a different JS build anyway.

Actual behavior

@electron-forge/plugin-webpack is invoked twice (once for each arch) and generates slightly different arranged JS output – contents are the same for me, but the position of chunks has changed – leading to the following error during any universal build:

[FAILED] Expected all non-binary files to have identical SHAs when creating a universal build but "Contents/Resources/app/.webpack/main/index.js" did not
[FAILED] Expected all non-binary files to have identical SHAs when creating a universal build but "Contents/Resources/app/.webpack/main/index.js" did not
[FAILED] Expected all non-binary files to have identical SHAs when creating a universal build but "Contents/Resources/app/.webpack/main/index.js" did not
An unhandled rejection has occurred inside Forge:
Error: Expected all non-binary files to have identical SHAs when creating a universal build but "Contents/Resources/app/.webpack/main/index.js" did not
at Object.makeUniversalApp (/Users/gitlab/builds/[REDACTED]/node_modules/@electron/universal/dist/cjs/index.js:113:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async packageUniversalMac (/Users/gitlab/builds/[REDACTED]/node_modules/@electron/packager/src/universal.js:56:3)
    at async Promise.all (index 0)
    at async packager (/Users/gitlab/builds/[REDACTED]/node_modules/@electron/packager/src/index.js:204:20)

I would assume, that this is a regression introduced by #3433

Steps to reproduce

Can't really hand out our application here, but since the solution seems easy enough: just build the JS only once or at least use the same JS for both parts of the universal binary, I don't think a reproducer is really needed. Very trivial applications do not show this issue (ie. just the template app (npm init electron-app@latest my-app -- --template=webpack) is not affected).

Additional information

No response

[MarshallOfSound]

Hm, I tested this with a rather complex app and the universal build worked. Specifically my PR #3433 actually fixed it's universal build, this sounds like you have a non deterministic loader or plugin as webpack builds in theory should be deterministic in the default case.

There is theoretical future piece of work where we could only run webpack once and simply do magic-native-module mappings to avoid this kind of issue 🤔 But that's non-trivial work.

This is also strange because universal should in theory fall back to making two asar's for the universal build instead of just bailing on you like that. That's probably a bug in @electron/universal, without seeing your config it's hard to tell but my hunch is setting asar: true in packagerConfig in your forge configuration would make this error go away 👍

[TheRealCuran]

Indeed asar: true fixes the issue as well (or at least works around it). Feel free to close the bug then.

Non-deterministic loader: not impossible to imagine, since this is an app I "inherited" and it had some other weird choices made as well. But sadly I do not have had enough time yet to go through the entire thing and clean it up.