apache / apache/maka

Desktop artifacts ship the renderer's dependency tree twice

Open
#3,146 2 comments 0 reactions 0 assignees View on GitHub
bug good first issue help wanted
Dominant language
TypeScript
Stars
5.4k
Forks
502
Avg merge
1d 2h
Merged PRs (30d)
715

Description

## Problem

`app.asar` carries the raw sources of packages that exist only to be bundled into the renderer. Vite already emits everything the renderer loads into `dist-renderer`; the second copy in `node_modules` is never read.

Measured against `main@794e760a9`:

| | Size |
|---|---|
| `dist-renderer` — what the renderer actually loads | **7.5 MB** |
| Same libraries again as raw `node_modules` inside `app.asar` | **~183 MB** |

Largest contributors: `mermaid` 80 MB, `lucide-react` 30 MB, `@astryxdesign` 22 MB, `@mermaid-js` 12 MB, `cytoscape-fcose` 9 MB, `react-dom` 7 MB.

## Why it happens

`electron-builder.config.mjs` declares `files: ['dist/**/*', 'dist-renderer/**/*', 'package.json', ...]`, which does not mention `node_modules`. electron-builder then adds the full production dependency closure on its own. `@maka/ui` is a production dependency of `@maka/desktop`, and it pulls in `mermaid`, `lucide-react`, `@astryxdesign/*` and `react`, so all of them ship whole.

Nothing loads them at runtime:

- `dist/main/**` and `dist/preload/**` contain no `require`/`import` of `@maka/ui`, `mermaid`, `lucide-react`, `react`, `react-dom`, `@astryxdesign/*`, `@xterm/xterm` or `@dnd-kit/*`.
- No main-process package depends on `@maka/ui`. The single hit in `packages/core/dist/display-redaction.js` is a comment, not an import.
- `dist-renderer/index.html` references only relative `./assets/*` paths, so the bundle resolves nothing from `node_modules`.

One package needs care: `@xterm/headless` **is** required by `packages/runtime` and must keep shipping. Only `@xterm/xterm` and `@xterm/addon-fit` are renderer-side.

## How it got here

Not any one change — three that were each reasonable alone:

| Date | Change | Effect |
|---|---|---|
| 07-26 | #1506 established the macOS release pipeline | production dependencies ship whole by default |
| 08-03 | #1929 added Mermaid rendering to Markdown | +80 MB, correctly code-split for the renderer |
| 08-05 | #2199 bundled a hermetic Git runtime | +151 MB (separate issue) |

Each author saw only their own slice, and **CI has no artifact-size gate**, so nothing reported the step changes.

## Proposal

1. Exclude the renderer-only tree from `files` in the electron-builder config, keeping `@xterm/headless`.
2. Add a packaged-size check to CI so a future step change is visible in the PR that causes it. Worth doing first — otherwise the reclaimed space returns in some other form within a couple of months.

Happy to take this one. Filing separately rather than folding it into a PR because the exclusion mechanism is a packaging-policy decision.

## Not included here

The bundled Git runtime is a larger and separate finding: of its 151 MB, ~78 MB is a .NET runtime and ~17 MB is a 2D graphics library, both belonging to Git Credential Manager, which Maka does not use — it keeps credentials in its own `credentials.json`. A further ~13 MB comes from the 27 git builtins having lost their hardlinks (414 files, 415 inodes). I will file that separately if it is wanted.

Contributor guide

Open the contributing guide

Research direction

Read electron-builder.config.mjs and inspect the CI workflows that build desktop artifacts. Compare the packaged app.asar contents with dist-renderer and dist/main or dist/preload, confirming that renderer-only dependencies are unused while @xterm/headless remains required by packages/runtime. Done means renderer-only dependencies are excluded, @xterm/headless still ships, and CI reports future packaged-size changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
electron, typescript
Domain
build-system, desktop, performance
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.