Skip to content

fix(release): unbreak Linux deb + Snap + Windows builds post-monorepo#47

Merged
JohnMcLear merged 1 commit into
mainfrom
fix/release-build-monorepo-paths
May 12, 2026
Merged

fix(release): unbreak Linux deb + Snap + Windows builds post-monorepo#47
JohnMcLear merged 1 commit into
mainfrom
fix/release-build-monorepo-paths

Conversation

@JohnMcLear
Copy link
Copy Markdown
Member

Summary

v0.4.0 was the first tag built under the new pnpm monorepo layout (PRs #29/#30, May 5). Three of the five release targets failed; only macOS (DMG + ZIP, both arches) and Linux AppImage made it into the draft release.

The three regressions:

  1. Linux .deb — fpm fatal: Parent directory does not exist: .../release/@etherpad - cannot write to .../release/@etherpad/desktop_0.4.0_amd64.deb. electron-builder uses package.json#name as the default deb artifact path + executable name. The new scoped name @etherpad/desktop makes the / literal in the output path.

  2. Snapexpected argument for flag '--executable' followed by ERR_ELECTRON_BUILDER_CANNOT_EXECUTE. Same cause: the snap --executable flag can't carry a scoped name.

  3. Windows[fetch-etherpad] failed: spawn pnpm ENOENT. The embedded-server fetch script spawns pnpm directly, but on Windows pnpm resolves to pnpm.cmd and Node's child_process.spawn won't find shims without shell: true.

Changes

  • `packages/desktop/build/electron-builder.yml`: add `linux.executableName: etherpad-desktop`. Pins a slash-free name for both deb and snap targets in one move.
  • `packages/desktop/scripts/fetch-etherpad.mjs`: add `shell: process.platform === 'win32'` to the `spawn` call. Same pattern used upstream in `ether/etherpad`'s `admin/scripts/gen-api.mjs`.

Test plan

  • CI must pass (Linux/macOS/Windows unit tests)
  • After merge: re-run the Release + Snap workflows on the v0.4.0 tag (or push v0.4.1 if v0.4.0 retag isn't desirable). Verify the existing v0.4.0 draft release picks up the missing artifacts: `etherpad-desktop_0.4.0_amd64.deb`, `Etherpad-Desktop-Setup-0.4.0.exe`, `Etherpad-Desktop-0.4.0-portable.exe`, `latest-linux.yml`, `latest.yml`, and the snap goes to the edge channel.

Notes

  • macOS DMG + ZIP + Linux AppImage all succeed at v0.4.0 (already in the draft release) — they use `productName`-derived names, not `package.json#name`, so they didn't hit the scoped-name bug.
  • v0.3.2 worked because it was built before the monorepo move when root `package.json#name` was the non-scoped `etherpad-desktop`.

🤖 Generated with Claude Code

Three regressions surfaced when v0.4.0 (the first release-please run
under the new monorepo layout) tried to build:

1. Linux `.deb` — fpm failed with "Parent directory does not exist:
   .../release/@etherpad". electron-builder defaults the deb artifact
   path + executable name to `package.json#name`, which is now the
   scoped `@etherpad/desktop`. The `/` from the scope became a
   directory in the output path.
2. Snap — `expected argument for flag '--executable'` followed by
   `ERR_ELECTRON_BUILDER_CANNOT_EXECUTE`. Same root cause as deb: the
   snap `--executable` argument can't carry a scoped name.
3. Windows — `[fetch-etherpad] failed: spawn pnpm ENOENT`. The
   embedded-server fetch script spawned `pnpm` without going through
   a shell, but on Windows pnpm resolves to `pnpm.cmd` which Node's
   `child_process.spawn` won't find without `shell: true`.

Fixes:

- Add `linux.executableName: etherpad-desktop` to
  `packages/desktop/build/electron-builder.yml`. That pins a
  slash-free name for both deb and snap targets in one shot.
- Add `shell: process.platform === 'win32'` to the `spawn` call in
  `packages/desktop/scripts/fetch-etherpad.mjs`. Same pattern we
  used upstream in ether/etherpad's `admin/scripts/gen-api.mjs`.

These are pre-existing post-#29/#30 regressions; v0.3.2 was built
before the monorepo move, so its non-scoped root name shielded it.

The macOS build + Linux AppImage already succeed at v0.4.0, so this
PR's verification is the next tag rebuild.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@qodo-code-review
Copy link
Copy Markdown

ⓘ You've reached your Qodo monthly free-tier limit. Reviews pause until next month — upgrade your plan to continue now, or link your paid account if you already have one.

@JohnMcLear JohnMcLear merged commit 599520c into main May 12, 2026
5 checks passed
@github-actions github-actions Bot mentioned this pull request May 12, 2026
JohnMcLear added a commit that referenced this pull request May 12, 2026
…ates (#49)

PR #47 added linux.executableName to fix snap's `--executable` flag
and the deb binary name — but the deb / snap output PATHS still come
from electron-builder's default artifactName templates which use the
${name} token (= package.json#name). That's now `@etherpad/desktop`
(scoped after the monorepo move), so:

- deb / snap write to `release/@etherpad/desktop_*` and crash with
  "Parent directory does not exist: release/@etherpad"
- Windows NSIS intermediate `release/@etherpaddesktop-*.nsis.7z`
  trips 7za's `@listfile` convention and fails with "Could not
  create destination file: No such file or directory"

Setting `extraMetadata.name: etherpad-desktop` in the
electron-builder config overrides package.json#name at build time
without touching the actual package.json (which we need to keep as
`@etherpad/desktop` for `pnpm --filter` and workspace deps). Every
artifact template that interpolates ${name} now sees the slash-free
name and the path issue goes away in one move.

Verified by inspecting the v0.4.1 build logs for both remaining
failures:
  - linux deb: fpm `--p ... cannot write to release/@etherpad/desktop_0.4.1_amd64.deb`
  - snap:      mksquashfs `Could not create destination file` on the
               same path shape (release/@etherpad/desktop_0.4.1_amd64.snap)
  - win nsis:  7za `Could not create destination file` on
               release\@etherpaddesktop-0.4.1-x64.nsis.7z (@-prefix
               triggers 7za's @ListFile mode)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant