Skip to content

[Feature Request] Upgrade the Electron build chain to Vite 8 #154

Description

@sheepbox8646

Affected area

Build / packaging

Problem or workflow pressure

The Electron application remains on Vite 7 while other repository build surfaces already use and validate Vite 8. Keeping two Vite generations in the workspace leaves the desktop build on the older Rollup-compatible configuration model and creates avoidable dependency and peer-version divergence.

The Electron upgrade must preserve the existing renderer behavior, especially WASM handling and the guarded Mermaid dependency chunk, rather than treating the dependency bump as an isolated package change.

Desired outcome

The Electron main, preload, and renderer builds should run on Vite 8 with a compatible React plugin and electron-vite release, while retaining the current shared aliases, WASM behavior, and Mermaid chunk boundary. Shared renderer helpers should remain consumable by workspace hosts that temporarily resolve different Vite majors.

Proposed solution

Upgrade the Electron dependency trio to Vite 8, @vitejs/plugin-react 6, and the Vite 8-compatible electron-vite 6 beta. Migrate renderer configuration from Rollup compatibility keys to Rolldown-native rolldownOptions and codeSplitting.groups, narrow shared helper types to the structural data consumers need, and record the documented Vite 8 compatibility of vite-plugin-wasm@3.5.0 in pnpm peer rules.

Alternatives or workarounds

The repository can keep Electron on Vite 7, but that prolongs split build behavior and dependency duplication. Upgrading only Vite without electron-vite, the React plugin, and the chunk configuration together would leave peer incompatibilities or silently change renderer output. Replacing shared helpers with Electron-local copies would avoid cross-major typing but duplicate build contracts.

Trade-offs or non-goals

The proposal uses a beta electron-vite release because stable Vite 8 support is not yet available there. It does not redesign renderer chunking, upgrade unrelated packages, or claim packaging validation for every operating system and architecture. The lockfile accounts for most of the PR's changed-line count.

Additional context

A pull request was opened before this required Issue step due to an authoring-process oversight: #89. The existing implementation and PR should not be treated as maintainer approval. No further scope expansion or PR progression is intended until a maintainer explicitly agrees that the scope and approach described here are appropriate.

Before submitting

  • I searched the existing issues and did not find a duplicate request.
  • This request concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
  • I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.
  • I will wait for a Lody maintainer to explicitly agree on the scope and approach before implementation or a pull request.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions