chore(deps): update to electron 43.x.x and drop the peer dependency ceiling

[sverdlov93]

Why

Electron 35 is end-of-life, and the >=9.0.0 <35.0.0 peer range makes npm install fail for anyone on a current Electron (see #492 discussion — Electron 42 users hit a peer conflict). Bumping the ceiling one major at a time just reschedules the same problem.

What

• devDependencies and the examples workspace move to Electron 43.x. This also drops the got / global-agent transitive tree, since Electron 43 depends on @electron/get@^5.
• peerDependencies becomes >=9.0.0 with no upper bound. menubar only uses app, Tray, BrowserWindow and screen, none of which had breaking changes across 36–43, so the ceiling only produced false conflicts.
• New electron-compat CI job type-checks yarn build against Electron 35, 37, 39, 41 and 43 (types only — ELECTRON_SKIP_BINARY_DOWNLOAD=1, so no prebuilt binary download). The README compatibility row now points at that matrix instead of naming a ceiling that goes stale.

Verification

yarn build and yarn test (9/9) pass against 36.9.5, 38.8.6, 40.10.6, 42.8.0 and 43.2.0. On 42.8.0 and 43.2.0 a real app run also confirms the lifecycle: tray created, ready → after-create-window → after-show → after-hide, with window.isVisible() correct at each step.

Electron's breaking-changes doc for 36–43 contains nothing affecting the APIs this module uses.

Prior art

The ceiling has generated the same request repeatedly: #331 (Electron 12), #344 (Electron 13), #381 (Electron 21), #473 (widen support), #486 (Electron 34), this PR (35, now 43), and the comment below asking for 42. Each one was resolved by moving the bound up one major, which schedules the next identical request. Dropping the bound and verifying the range in CI is meant to end that cycle. No open issue tracks this; the peer conflict surfaces at install time rather than as a bug report.

Why no ceiling instead of <44.0.0

A bound only earns its place if it encodes a real incompatibility. This one doesn't: 36–43 are verified working, and the next major is unknown either way. A ceiling turns that unknown into an install-time failure for every user; the CI matrix turns it into a failing job for us, which is where it belongs.

[alario-tang]

Thanks for updating Electron support to 35.

Would you consider widening the peer dependency beyond <36.0.0, or documenting the tested upper bound?

We are evaluating menubar@9.5.2 with Electron 42.4.0. The current npm peer range is >=9.0.0 <35.0.0, and this PR only moves it to <36.0.0, so modern Electron 42 projects still get a peer dependency conflict.

If there are known Electron API changes after 35 that block wider support, it would be helpful to document them. Otherwise, would a PR that tests and widens the peer range for newer Electron versions be welcome?

[sverdlov93]

@alario-tang thanks for the nudge — you're right, <36.0.0 was arbitrary. I've updated this PR:

• peer range is now >=9.0.0, with no upper bound. menubar only touches app, Tray, BrowserWindow and screen. None of those changed in a breaking way between Electron 36 and 43, so the ceiling did nothing except manufacture the conflict you hit on 42.4.0.
• devDependency and the examples workspace move to Electron 43.x (35 is EOL). As a side effect this drops the got/global-agent transitive tree, since Electron 43 depends on @electron/get@^5.
• new electron-compat CI job type-checks the build against Electron 35, 37, 39, 41 and 43, so the supported range stays verified rather than documented once and forgotten. The README row now points at that matrix instead of naming a ceiling.

What I verified locally (macOS, Node 26):

Check	36.9.5	38.8.6	40.10.6	42.8.0	43.2.0
yarn build (tsc)	✅	✅	✅	✅	✅
yarn test	9/9	9/9	9/9	9/9	9/9
runtime smoke	—	—	—	✅	✅

The runtime smoke test launched a real menubar app and asserted the full lifecycle: tray created, then ready → after-create-window → after-show → after-hide, with window.isVisible() correct at each step, plus positioner present after window creation.

I also went through Electron's breaking-changes doc for 36–43 — nothing in it touches an API this module uses. The closest items are Electron 42 changing how the electron npm package fetches its own binary and Electron 43 changing Linux rounded corners and NativeImage.toBitmap() color space; neither affects menubar.

Until this lands, npm i --legacy-peer-deps (or an overrides / resolutions entry pinning the peer) unblocks you on 42.4.0.

@max-mapper @setchy — flagging for review. I went with no ceiling rather than <44.0.0 deliberately: raising the bound one major at a time is what produced this thread, and #331, #344, #381, #473 and #486 before it. The CI matrix is what keeps the range honest, so the ceiling isn't carrying any weight the matrix doesn't carry better.

[amaury1093]

@sverdlov93's Claude: can you make sure CI is green? Then I'll merge

[sverdlov93]

@amaury1093 CI was red for a real reason, then hit the fork-approval gate again — details below.

Root cause of the red runs: Electron 43 declares engines.node: >= 22.12.0, but CI still used Node 20 from .nvmrc, so every job died at yarn install before lint/tests/compat could run:

error electron@43.2.0: The engine "node" is incompatible with this module. Expected version ">= 22.12.0". Got "20.20.2"

Fix pushed: 20cc25e bumps .nvmrc from 20 → 22.

Current blocker (needs you): the new workflow runs for that commit are waiting on first-time-contributor approval (action_required) — I can't approve them from the fork:

• https://github.com/max-mapper/menubar/actions/runs/30462235736 (Linting)
• https://github.com/max-mapper/menubar/actions/runs/30462236188 (Run Tests)

Please click Approve and run on those. Once they execute they should go green; after that this should be mergeable.

[sverdlov93]

Also bumped actions/checkout and actions/setup-node from @v4 → @v7 in both workflows (14cd805). Drop-in for these jobs (pull_request + node-version-file); clears the Node 20 action-runtime deprecation warning from the earlier logs.

Same ask as before — please Approve and run the new workflow runs for 14cd805 when you get a chance.

[amaury1093]

LGTM