Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
3 tasks done
busterbogheart opened this issue Jul 17, 2024 · 9 comments · May be fixed by #3884
Open
3 tasks done

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

busterbogheart opened this issue Jul 17, 2024 · 9 comments · May be fixed by #3884
Assignees
@erickzhao
Labels
bug package Issues related to the `package` command platform/macOS

Comments

@busterbogheart
Copy link

busterbogheart commented Jul 17, 2024 •
edited
Loading

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.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
@erickzhao erickzhao added bug package Issues related to the `package` command platform/macOS labels Jul 18, 2024
@busterbogheart
Copy link
Author

Does anyone have some pointers here?

@busterbogheart
Copy link
Author

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
Copy link
Author

busterbogheart commented Aug 5, 2024 •
edited
Loading

@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
Copy link
Author

@erickzhao Hello?

@busterbogheart
Copy link
Author

@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
Copy link
Author

Hello please

@ariestav
Copy link

@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!

@erickzhao erickzhao self-assigned this Dec 12, 2024
@erickzhao erickzhao added the bug label Feb 8, 2025
@busterbogheart
Copy link
Author

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

@busterbogheart
Copy link
Author

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

busterbogheart pushed a commit to busterbogheart/forge-arch-fix that referenced this issue Mar 13, 2025
fix(osxUniversal): set appropriate archs in process.env for Mac unive…
17c06fd 
…rsal builds

issue electron#3657
@busterbogheart busterbogheart linked a pull request Mar 13, 2025 that will close this issue
Open
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@erickzhao erickzhao

Labels
bug package Issues related to the `package` command platform/macOS
Projects
None yet
Milestone
No milestone
3 participants
@ariestav @erickzhao @busterbogheart