Yarn 4.18's default is `enableScripts: false`; the version bump kept the
old behaviour by setting it back to true, which re-enables arbitrary
install-time code execution for every package in the tree. Turn it off
again and opt in only where a package actually has to build something.
The list is exactly what Yarn reports as YN0004 with scripts disabled:
@parcel/watcher, @swc/core, and esbuild (keyed by bare name so it covers
both 0.25.12 and 0.27.7). electron and sharp are deliberately absent —
electron ships no lifecycle scripts and sharp resolves prebuilt binaries
through optional platform packages, so neither needs to build.
The workspace's own `postinstall` (electron-builder install-app-deps) is
unaffected: enableScripts only governs dependencies.
Verified with a from-scratch `yarn install --immutable`, the full `yarn
check`, and an `electron-builder --linux dir` pack.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BtCagWFcr4MLHQD4zkPVf5
Two config keys come with this. `enableScripts` flipped its default to
false in the 4.13 line as supply-chain hardening, so it has to be set
explicitly here — esbuild, @swc/core and @parcel/watcher all need their
install scripts, as does the `electron-builder install-app-deps`
postinstall. `yarn set version` also wrote `approvedGitRepositories: **`,
a blanket opt-out of the new git-dependency approval prompt; that is
dropped again, since the lockfile has no git dependencies and leaving the
guard armed costs nothing until one is added.
The lockfile moves to metadata version 10 and one builtin patch hash for
`resolve` changes; no package resolutions move.
Incidentally this makes `--no-time-gate` available on `yarn add`/`yarn up`,
which 4.11 did not have — the npmMinimalAgeGate quarantine previously had
to be worked around with YARN_NPM_MINIMAL_AGE_GATE=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BtCagWFcr4MLHQD4zkPVf5
26.16.1 carries the fix for electron-userland/electron-builder#10167:
`security set-key-partition-list` was passed the .p12 import password
(CSC_KEY_PASSWORD) instead of the temporary keychain's own password, so
macOS signing could fail in CI whenever those two differ. The fix landed
after 26.16.0 was cut, so 26.16.1 is the first release that has it.
The version is spelled out explicitly because the `latest` dist-tag still
points at 26.15.3 — 26.16.x ships under the `v26` tag.
Verified unchanged in 26.16.1, since both are load-bearing here:
- the legacy snap template table (base/plugs pairing behind #3002)
- the appimage 1.0.3 toolset checksums (libfuse2-free runtime, #3022)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BtCagWFcr4MLHQD4zkPVf5
Setting `base: core22` left the snap declaring a core22 base while still
plugging the core18-era gnome-3-28-1804 content snap for its GNOME platform.
Mesa's DRI drivers in that platform cannot resolve their dependencies against
core22, so every GL/EGL path fails including the swrast software fallback, the
GPU process exits, and the main process segfaults before a window appears.
The base override never moved the platform. electron-builder's snap template
pairs `base: core20` with a hardcoded `gnome-3-28-1804` plug, and its legacy
snap path rewrites only the `base` field, leaving the plugs block untouched.
The two halves have to match, so the fix is to stop overriding the base and
let the template stay self-consistent.
Dropping the key rather than pinning core20 explicitly means the snap keeps
following whatever electron-builder's template ships.
This restores the pre-3.68 behaviour, which reopens#2614 for very new GPUs
whose hardware needs a newer Mesa than the platform provides. That trade is
deliberate: #2614 affected some GPUs, this affects every user.
Fixes#3002
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KboMatXCuTgjD6KfC1ik12
electron-builder's default AppImage toolset ("0.0.0") uses the legacy
AppImageKit runtime, which dlopens libfuse.so.2 at startup and fails on
distros that no longer ship libfuse2.
Opting into toolset appimage 1.0.3 uses AppImage/type2-runtime 20251108,
a static-pie runtime with libfuse/squashfuse linked in, so the AppImage
runs without any FUSE packages installed.
Fixes#3022
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MmsuZZPx6pFKSjN6UZmGcJ
The snap defaults to core20 (Ubuntu 20.04) which bundles Mesa drivers
too old for newer GPUs (e.g. Intel Arrow Lake 8086:64a0). Setting base
to core22 pulls in the Ubuntu 22.04 GNOME platform snap with updated
Mesa drivers, fixing segfaults on launch.
Fixes#2614
see api.md for docs
also:
- allow passing arguments when using CLI to pass to second instance
- allow opening files from API
- improve docs
#980#974#1347
Claude
Mikael Finstad
dependabot[bot]
Kyle Kasten
talynone