Vite plugin: support `nodeIntegration: true` in the renderer process.

[hab25]

Pre-flight checklist

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project uses.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem description

When using the electron forge vite plugin, configuring vite for nodeIntegration: true in the renderer process requires too much of vite-specific knowledge and configuration. Further, even if one makes it work, there is no guarantee that it won't break on future updates of the plugin since it such configuration could interfering with internal assumptions of the plugin.

Proposed solution

Something like the webpack plugin does for this use case. See https://github.com/electron-forge/electron-forge-docs/blob/f83f6237a6e0018c426a1b7efddc8098eca2c01c/config/plugins/webpack.md?plain=1#L269 .

Alternatives considered

• fragile "Manual" vite configuration as described above.
• shifting a lot of what would be in the renderer into the preload script (incurs more boilerplate and complexity).

Additional information

No response

[RNAdvani]

@erickzhao @dsanders11 Hi, I would like to work on this enhancement feature, I have been reading the documentation and found that plugin-vite is experimental, there should a nodeIntegration option for vite plugin same as webpack plugin, this would be a great enhancement for the plugin.

My proposed plan is to:
Add a nodeIntegration option to the Vite plugin's configuration, just like the Webpack plugin has.
When this option is true, I will update the Vite config to mark all of Node.js's built-in modules (like 'fs', 'path', etc.) as "external". This will tell Vite not to bundle them, which should achieve the goal.

This will ensure Vite avoids bundling these modules, aligning the behavior with expected Node.js runtime

Does this sound like the right technical approach? I'm ready to start working on a PR if this aligns with the project's goals.
Thank you!.

[RNAdvani]

@hab25 can u provide me config if you have found a solution to make it work with nodeIntegration:true

[hab25]

@RNAdvani I haven't found one, so I'm using preload.

[nkallen]

Plasticity.xyz will offer a $2,500 bounty for anyone who can get support for nodeIntegration: true with the vite plugin implemented and merged into forge.

[rafael81]

Submitted PR #4258 for this bounty: #4258

Scope:

• adds renderer[].nodeIntegration to @electron-forge/plugin-vite
• externalizes Electron/Node built-ins and uses Node-oriented resolve settings for those renderer builds
• documents the option and adds ViteConfig regression coverage

Validation is included in the PR body. This work was prepared with AI assistance and manually reviewed before submission.

[tzh476]

@nkallen — a status note on this issue, since you funded it and there is now a finished implementation you may not have seen.

PR #4317 implements nodeIntegration: true for the Vite plugin. It builds on @rafael81's #4258 (he is retained as a co-author on the commits) and keeps that PR's renderer-level API.

Why a second PR was needed. #4258 externalises Electron and Node built-ins, which is necessary but not sufficient: it leaves bare ESM imports in the renderer output, and Vite loads that output as a browser module, so it fails before application code runs:

Uncaught TypeError: Failed to resolve module specifier "electron".
Relative references must start with either "/", "./", or "../".

The dev server has the matching problem — it resolves Node built-ins to Vite's browser-external stubs. #4317 adds a node-integration Vite plugin that keeps those imports resolvable in both the build and the dev server.

Current state, verified rather than asserted:

• #4317 is MERGEABLE, ahead by 2 / behind by 0 — no rebase needed
• #4258 is behind and was last updated 2026-05-13
• I ran the project's own CI locally against the pinned toolchain (yarn@4.10.3, node 20.19.6): yarn install --immutable clean, yarn build clean, yarn lint exit 0 (51 pre-existing warnings, 0 errors), and yarn test:fast → 54 files passed, 380 tests passed
• The feature's own tests are a real control, not a rubber stamp: reducing the node-integration plugin to a name-only shell fails 3 tests (preserves Node and Electron imports in production builds, serves Node and Electron imports through runtime shims, keeps user dependency and Rollup settings), and restoring it returns 19/19 green in-package

The one thing blocking it is not code. All three workflows on #4317 sit at action_required — the first-time-contributor gate — so the test suites have never actually run in CI. The three green checks visible on the PR are two Socket Security scans and a label bot; by comparison, the two most recent externally-contributed PRs that merged (#4322, #4276) each ran 13–15 checks including required-ci, fast-tests and slow-tests across three platforms. A maintainer approving workflows would let CI run, and locally it goes green.

I am not asking you to do anything about that — you funded the work, you do not maintain the repo. This is a status note so the bounty you offered is not sitting behind an implementation you did not know was finished. Happy to answer questions or split the bounty with @rafael81 in whatever way you and the maintainers think is fair, given #4317 builds directly on #4258.

Disclosure: this work was done with LLM assistance, and I take responsibility for it — I can explain any part of the diff and the tests were verified as described above.