Conversation
…rsion Main and preload bundles were built for Vite's browser-oriented default target and the renderer for a generic browser baseline, downleveling code for engines Electron never runs. Resolve the project's Electron version once per config generator and map its major to the Node.js and Chromium versions it ships (table ported from electron-vite), then use those as `build.target`. A `build.target` in the user's own Vite config still wins, and if the Electron version cannot be resolved no target is set. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HaWs2TmeyNyMACXbFqjixc
…-chromium The hand-copied Chromium column went stale as soon as a new Electron major shipped: Electron 42 clamped down to chrome146 instead of its actual chrome148. Take the Chromium major from electron-to-chromium, which is published with every Electron release, and keep only the Node.js column in the local table. Also correct the Electron 40 entry to the Node.js version 40.0.0 shipped (24.11, not 24.14), fold the clamp into the table lookup so a gap degrades to the next-lower entry instead of dropping the targets, and mark the ConfigEnv field as internal. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HaWs2TmeyNyMACXbFqjixc
Preload scripts run in the renderer process, so they execute on Chromium's V8, not on Electron's Node.js build. Targeting Node.js made the bundle downlevel syntax the engine supports natively: with Electron 38 a preload got node22.19, rewriting `using` declarations even though it runs on Chrome 140's V8. Use the Chrome target for preload instead, overriding the Node.js default from getBuildConfig; a user-supplied build.target still wins. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HaWs2TmeyNyMACXbFqjixc
Review found three problems with the target table and its typings: - `forge-vite-env.d.ts` imported `ElectronTargets` from `src/`, which pulled `src/config/electron-targets.ts` — and with it the untyped `electron-to-chromium` — into every consumer's TypeScript program, failing `tsc` with TS7016 in a scaffolded app (the types package is a devDependency, and `skipLibCheck` does not cover a `.ts` file). Declare the shape inline in the augmentation instead. - Electron 38.0.0 ships Node 22.18.0, not 22.19.0. Correct it, and add the 42, 43 and 44 entries so current releases stop clamping to 41. Every value is checked against `electron/electron`'s DEPS at `vX.0.0`. - The lookup relied on the table being written newest-first, so an appended entry would have been silently ignored. Sort it instead, and say so where maintainers are told to extend it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HaWs2TmeyNyMACXbFqjixc
Drop electron-to-chromium in favour of a Chromium column in the target table, covering Electron 28 through 44. Also trim the comments. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HaWs2TmeyNyMACXbFqjixc
They were copied from the neighbouring fixtures and suppressed nothing except an unused `using` binding in two files, which now returns the binding instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HaWs2TmeyNyMACXbFqjixc
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM, straightforward config-derivation feature.
Reviewed: the Electron-major-to-target lookup table and its fallback/parsing logic in electron-targets.ts, the memoized resolveElectronTargets() promise and its try/catch fallback to {} in ViteConfig.ts, and how electronTargets flows into build.target for main/preload/renderer configs. Confirmed via electron-targets.spec.ts that falling back to the newest known entry for majors beyond the table (e.g. 45, 999) is an intentional, tested behavior rather than a bug. Also confirmed user-supplied build.target in vite config still overrides the derived value.
Extended reasoning...
Self-contained feature addition to @ electron-forge/plugin-vite: a new lookup table module, wiring it into ConfigEnv via a memoized async resolver with try/catch fallback, and using the resolved target in three existing config builders. No auth, crypto, or data-exposure surface; worst-case failure mode is an unset or slightly-stale build.target, not a functional break. Test coverage is thorough (unit tests for the table plus generator-level tests covering resolution failure and user-override precedence), and the diff is small and mechanical enough that a human need not re-review.
This branch has not been deployed
2 participants
Summarize your changes:
Inspired by
electron-vite, this PR dynamically changesbuild.targetfor every Electron major to keep the output JS as modern as possible based on the Electron runtime.🤖 Generated with Claude Code
https://claude.ai/code/session_01HaWs2TmeyNyMACXbFqjixc
Generated by Claude Code