Tracking M1 support progress.

[Hazzard13]

Exactly like the title is asking, is there anywhere I can check, like a tag, pull request, forum post, or anything else that I can follow as a single source to see how native M1 support is going?

I know the biggest blocker is Electron v11 support (the only Electron version to support building on ARM), no question. I can also see that Atom just updated to Electron v9, a major jump, which is super encouraging, but is there any ongoing work to upgrade even further?

Again, not even looking to force anyone to tackle all the work right now, I just want something I can keep tabs on, as I currently have a note I check with links to track the progress of all my most important libraries, tools, etc to make sure I know as soon as I can switch to a native build, and how it's going. Thanks so much!

[ThatXliner]

I don't think there's an official pinned PR/issue that has a todo list, but closest I know is issue #21688.

On second thought, why hasn’t an maintainer made an official TODO-issue yet. Maybe this thread can be it...

[sadick254]

Hey @Hazzard13 as you have stated the biggest blocker to M1 support is electron 11. Before updating to electron 11 there are a couple of things we have to do.

• Ensure Atom on electron 9 works without any regression.
• Migrate our native modules from Nan to N-api
• Open a pull request to update Atom to use electron 11 or the latest version that we will be able to update to.

[Hazzard13]

Ah, thanks so much for the update! It's good to have a clear list of what's standing in the way.

Since the electron 9 upgrade got merged, there's been basically no up-to-date information on what the blockers are. I'll keep an eye out for any pull requests on these issues!

[aminya]

Migrate our native modules from Nan to N-api

I just wanted to mention that this is not a requirement for Electron 11, but definitely very good changes to do in the long run.

Making the native modules context-aware must be done for Electron 12 based on this issue, so technically we can use Electron 11 with a deprecated option app.allowRendererProcessReuse = false (as we are already doing it).

For Electron 12, as mentioned in this comment, we can also use context-aware native modules without the need to transfer to N-API. For example, Atom/Keytar became compatible in this pull request:

atom/node-keytar#182

[sadick254]

It is true that we can update to electron 12 by making the native modules context-aware. However, this alone can't shield us from v8 changes that may break our native modules. There are long term benefits of transferring the native modules to N-API sooner rather than later. This has formed our decision to migrate the native modules to N-API before doing another electron upgrade.

[Hazzard13]

It is true that we can update to electron 12 by making the native modules context-aware. However, this alone can't shield us from v8 changes that may break our native modules. There are long term benefits of transferring the native modules to N-API sooner rather than later. This has formed our decision to migrate the native modules to N-API before doing another electron upgrade.

More than fair! I can't expect the team to prioritize the M1-specific benefits over big improvements for everyone, especially with just how well Atom is already working through Rosetta today. I'll look forward to using all these upgrades when they come!

[esba1ley]

Chalk up another eager user wanting to see native support for ARM, both for the M1 under MacOS and other ARM processors on Linux (e.g. Raspberry Pi Broadcom ARM chips).

[michalmiddleton]

Atom 1.61 beta has an update for Electron to v11.4.7 (#22687)
Based on the conversation above, this may be one of the steps leading to arm64!