fix(core): guard against archs dropped by Electron 44 (win32/ia32, linux/armv7l)

[erickzhao]

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project follows, as appropriate.
• The changes are appropriately documented (if applicable).
• The changes have sufficient test coverage (if applicable).
• The testsuite passes successfully on my local machine (if applicable).

Summarize your changes:

Forward-port of #4328 from main to next, as part of the next → main transition audit. It is a cherry-pick of that commit with the following adaptations for next:

• ESM import paths (.js extensions) in package.ts and parse-archs.ts.
• packages/api/core on next did not depend on semver, so it is added to dependencies (already in the lockfile via other workspaces).
• next no longer has the PackagerArch cast / Options type in package.ts, so targetArchs is passed straight into PackagerOptions.arch.

Behaviour is unchanged from the original: --arch=all filters out win32/ia32 and linux/armv7l for Electron >= 44.0.0-alpha.4 with a warning, and explicit requests for those archs fail with a descriptive error instead of a download 404.

Verified locally: yarn build, oxfmt/oxlint, yarn constraints, yarn knip, the full packages/api/core fast suite (131 passed), and the two new cases in package.slow.spec.ts.

Note: yarn install on current next fails in postinstall because of the orphaned packages/template/{vite,webpack}-typescript/spec directories left by #4229. #4374 fixes that; this PR's CI will need it merged first.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Bb2CkBAwF2iaKw1fjfQd9h

---

Generated by Claude Code

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🔴 packages/api/core/src/api/make.ts — parseArchs() now throws for explicit dropped archs (win32/ia32, linux/armv7l on Electron>=44) and silently filters them out of --arch=all, but make.ts calls parseArchs the same way even when skipPackage=true, where the app was already packaged (possibly under an older Electron) and no download ever happens. A user running forge make --skip-package after bumping Electron to >=44 in package.json now gets a hard failure for an explicit arch that is already packaged on disk, or silently loses distributables for archs already present when using 'all'. Fix: only apply assertSupportedArch/filterSupportedArchs validation on the code path that actually invokes the packager (skipPackage=false), or check for existing packaged output before rejecting/filtering in make.ts.

  Extended reasoning...

  Before this diff, parseArchs (packages/api/core/src/util/parse-archs.ts) simply split the declared arch string or returned every official arch for 'all', with no version-based rejection; make.ts's call at line 314-318 (unchanged by this diff) worked purely off the on-disk packaged directories. After this diff, the same parseArchs call now runs assertSupportedArch/filterSupportedArchs (packages/api/core/src/util/supported-archs.ts) using electronVersion resolved fresh from the current package.json, independent of whether packaging actually ran. Scenario: user packages an app for win32/ia32 with Electron 43, then later bumps the electron devDependency to 44.x and runs forge make --skip-package --arch=ia32 --platform=win32 to remake distributables from the already-packaged output (make.ts line 249: skipPackage=true skips listrPackage entirely via task.skip()). The 'Making distributables' step at line 314 still calls parseArchs(platform, arch, electronVersion), which now throws 'Cannot build for win32/ia32: Electron >= 44 no longer publishes...' even though the packaged directory already…

  Verification: normal (regression on the --skip-package make path). make.ts imports the changed parseArchs (line 25) and calls it unconditionally at lines 314-318 inside the "Making distributables" task, which runs even when skipPackage=true (options default line 111; package step skipped at lines 261-266). Per the diff, base parseArchs never validated/filtered: explicit archs returned… | normal. The base…

[claude]

🟡 (optional) filterSupportedArchs() calls console.warn() unconditionally, unlike the codebase's existing convention (see the adjacent warn(interactive, ...) call in package.ts) of gating console output on the interactive option so programmatic/API consumers (default interactive: false) get no unsolicited stdout/stderr. Now any --arch=all package/make run on Electron >= 44 prints to stderr even when the caller explicitly wants silent operation. Fix: thread an interactive (or silent) flag from package.ts/make.ts through parseArchs()/filterSupportedArchs() and only warn when true, matching the appVersion warning in package.ts.

Extended reasoning...

package.ts's own convention: the appVersion warning at package.ts:430 is wrapped in warn(interactive, ...) from util/messages.ts, which only calls console.warn when interactive===true; the CLI always passes interactive:true, but the JS API defaults interactive=false (used by embedders/CI wrappers/tests calling api.package()/api.make() directly). parse-archs.ts calls filterSupportedArchs(platform, archs, electronVersion) with no interactive parameter, and filterSupportedArchs unconditionally calls console.warn for every dropped arch it filters out of an 'all' expansion. Any programmatic consumer building for arch: 'all' on Electron >= 44 (win32 or linux) now gets stderr output it never opted into, breaking the silent-mode contract the rest of package.ts maintains, and polluting logs/output captured by tools that assume interactive:false means no console noise.

Verification: nit. Real and reachable but non-breaking. supported-archs.ts:78 calls console.warn() unconditionally inside filterSupportedArchs(). That function is invoked from parse-archs.ts:25 (the declaredArch === 'all' branch), which is called at package.ts:401 parseArchs(platform, arch, electronVersion) — no interactive flag is threaded anywhere along this path (filterSupportedArchs' signature has no…

[claude]

Code review found no issues

No high-confidence issues detected in this change.