build(deps): upgrade Electron to 44.4.3

[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). — n/a, no user-facing behavior change
• The changes have sufficient test coverage (if applicable). — existing suites cover the touched fixtures
• The testsuite passes successfully on my local machine (if applicable). — with one pre-existing environment caveat, noted below

Summarize your changes:

Brings the root electron devDependency to latest and moves the two spec fixtures that pinned real Electron versions off stale pins. Nothing user-facing changes.

electron 42.3.3 → 44.4.3

Forge 8 already handles Electron 44: supported-archs.ts carries isArchDroppedByElectron44 for the win32/ia32 and linux/armv7l drops in 44.0.0-alpha.4, @electron/packager is already at 20.3.0 (the release that stopped reporting those archs), and a slow spec already exercises electron: '44.0.0'. CI covers ubuntu-x64, darwin-arm64 and win32-x64 only, none of which Electron 44 dropped.

node-abi 4.24.0 → 4.35.0 (lockfile only)

4.24.0 only knew Electron up to 40.0.0-alpha.2, so it could not resolve an ABI for Electron 42 — the version already in use — let alone 44:

before: getAbi('42.11.6', 'electron') -> throws
after:  42 -> 146, 43 -> 148, 44 -> 149, 45 -> 150

That was a pre-existing gap in native-module rebuilds rather than something this upgrade introduced. node-abi is pinned by @electron/rebuild at ^4.2.0, so this needed no manifest change.

Spec fixtures

plugin/fuses/spec/fixture now tracks the root Electron through a file: link instead of pinning 39.2.3, matching what api/core/spec/fixture/api-tester already does for both electron and @electron/fuses. That fixture asks whether the fuses plugin works with the Electron this repo develops against, so tracking the root devDependency is the question it should be asking. It also removes the drift permanently: a file: dependency has no registry version, so Dependabot cannot open a PR against it — which supersedes #4409.

plugin/webpack/spec/fixtures/apps/native-modules goes ^33.3.1 → ^44.4.3, with package-lock.json regenerated by npm install --package-lock-only rather than edited by hand. This one deliberately keeps a pinned range instead of tracking the root: its spec runs npm ci, which requires manifest and lockfile to stay in sync, and the fixture's purpose is a real registry install plus native rebuild that a link into the Yarn-managed root node_modules would bypass.

That regenerated lockfile shrinks from 81 to 24 packages (59 removed, 2 added). Electron 44 swapped its download stack — @electron/get moved off the got dependency tree onto undici, and onto @electron-internal/extract-zip — so the got-era transitive deps (cacheable-request, decompress-response, @sindresorhus/is, @types/yauzl and friends) are simply gone.

The 16 fixtures pinning 99.99.99, 1000.100.10 or ^1000.0.0 are left alone. Those are deliberate sentinels, resolved without inspecting an install, not versions that can be upgraded.

Validation

• tsc -b packages clean; yarn lint:js reports no errors
• Fast suite: 66 files, 656 passed
• plugin/fuses slow-verdaccio suite passes (1/1) both with an exact 44.4.3 pin and with the file: link. The Electron download cache confirms 44.4.3 is what was packaged and launched, and that 39.2.3 was never fetched.
• AssetRelocatorPatch slow suite is unchanged from baseline at 7 passed / 2 failed
• native-hello-world@2.0.0, published in 2019, compiles cleanly against Electron 44 headers

The environment caveat: those 2 AssetRelocatorPatch failures are runs the app with the native module (Development and Production), failing with FATAL: Running as root without --no-sandbox is not supported. They are a limitation of the container I ran in, not this change — I reverted to the base commit, reinstalled at Electron 42.11.6, and reproduced the identical two failures. The binary that dies is the fixture's own Electron in a temp dir, and the spec invokes it via npm start → npx electron . without --no-sandbox. CI does not run as root, so these pass there.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LqP44h5cpf69eZPBwGSZmo

---

Generated by Claude Code

[socket-security]

All alerts resolved. Learn more about Socket for GitHub.

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

View full report

[claude]

Looks good, straightforward Electron version-bump change. Reviewed the root and fixture devDependency bumps (electron ^42.3.3 to ^44.4.3, and 33.3.1 to ^44.4.3), the fuses fixture's switch from a pinned electron version to a file: reference into the workspace-hoisted node_modules/electron (path depth verified correct), the regenerated native-modules package-lock.json (got-era deps removed in favor of undici/@ electron-internal/extract-zip, matching Electron 44's new download stack), and the yarn.lock node-abi bump. No application source or logic files are touched.

Extended reasoning...

Pure devDependency/toolchain upgrade across package.json, a test-fixture package.json, its package-lock.json, and yarn.lock; no security-sensitive code paths (auth, crypto, permissions) are touched. Verified the file: path in the fuses fixture resolves correctly (5 levels up to repo root/node_modules/electron), and the lockfile diffs match the PR description's claims about dependency stack changes. CODEOWNERS is a blanket repo-wide team entry, not a specific sensitivity signal, and the diff is small, mechanical, and self-contained.