using `electron/universal`, some modules do not rebuild according to `arch`

[busterbogheart]

Pre-flight checklist

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

Electron Forge version

7.4.0

Electron version

v24.1.1

Operating system

macOS 11.3.1

Last known working Electron Forge version

--

Expected behavior

Using electron/universal configured with osxUniversal in forge config, we expect all dependent modules will receive the correct arch and build themselves accordingly.

Actual behavior

We are using ffmpeg-static in our Electron app, but when the universal build is created, only the arm64 ffmpeg binary exists. I have confirmed that the ffmpeg-static module can be rebuilt in CLI with an arch param (npm rebuild --arch=x64 -f ffmpeg-static and confirmed with file node_modules/ffmpeg-static/ffmpeg). In this case the correct binary is build/fetched. But when running the universal build with forge, only os.arch() seems to be respected, which in this case is an M1 machine.

It seems electron-forge isn't passing the correct arch to dependencies. If there were hooks in the universal build process, or some env vars set, I could manually rebuild this one ffmpeg module according to an arch. For example ffmpeg-static does obey process.env.npm_config_arch, so if I were able to set that in between the x64 and arm64 builds (or electron/universal did), the module would build the correct ffmpeg binary.

I have attempted using hooks in electron-forge to try and switch based on arch, but that value is always universal. Also, building the app on separate Intel and M1 machines does produce the appropriate ffmpeg binary.

Steps to reproduce

Set up a project with electron-forge and ffmpeg-static, then attempt a universal Mac build.

Additional information

No response

[busterbogheart]

Does anyone have some pointers here?

[busterbogheart]

I have confirmed that when specifying process.env.npm_config_arch as arm64 even on an Intel machine, the app builds with the correct binary of ffmpeg.

Like process.env.npm_config_arch=arm64 npm run make -- --arch=arm64

[busterbogheart]

@erickzhao This line that worked above required me to hack into /core/dist/api/package.js and set process.env.npm_config_arch = target.arch in a few spots. I'm not sure which one did the trick. Can someone review, verify, and possibly make a PR?

[busterbogheart]

@erickzhao Hello?

[busterbogheart]

@malept @erickzhao @VerteDinde As it is, we're blocked from building universal Mac builds in CircleCI. And I suppose other people would be helped by this, too.

Could someone review this fix and see if it is possible to integrate?

[busterbogheart]

Hello please

[ariestav]

@malept @erickzhao @VerteDinde Is there any update on this issue? We'd like to move forward with this framework, but this issue is causing issue in our automated build process. Any insight into this would be most appreciated!

[busterbogheart]

Checking in again, is there a plan for this ticket?

[busterbogheart]

For anyone interested, this is the point I set the process.env.npm_config_arch which works for our builds:

        }, async (childTrace, _, task) => {

            process.env.npm_config_arch = target.arch;

            return (0, tracer_1.delayTraceTillSignal)(childTrace, task.newListr([
                {
                    title: 'Copying files',
                    task: childTrace({ name: 'copy-files', category: '@electron-forge/core' }, async () => {
                        await addSignalAndWait(signalCopyDone, target);
                    }),