feat: add support for snap core24

[mmaietta]

Adds first-class core24 snap support through a new snapcraft config key, and restructures the snap target into per-core classes so each base gets its own code path.

The old snap key still works exactly as before — nothing breaks for existing users. The new snapcraft key gives you structured access to core18/20/22 (same behavior as before) and core24 (all-new).

---

New config shape

// electron-builder.json
{
  "snapcraft": {
    "base": "core24",
    "core24": {
      "useDestructiveMode": true,   // or useLXD / useMultipass / remoteBuild
      "extensions": ["gnome"],       // defaults to ["gnome"] unless destructive mode
      "stagePackages": ["default", "libdrm2"],
      "allowNativeWayland": true
    }
  }
}

For legacy bases:

{
  "snapcraft": {
    "base": "core22",
    "core22": {
      "confinement": "classic",
      "stagePackages": ["default", "libsecret-1-0"]
    }
  }
}

Pass-through mode for teams that manage their own snapcraft.yaml:

{
  "snapcraft": {
    "base": "custom",
    "custom": { "yamlPath": "build/my-snapcraft.yaml" }
  }
}

---

core24 specifics

• Default build uses the gnome extension (handles content snaps, GTK theming, GPU). Explicitly set extensions: [] to opt out.
• gnome extension is incompatible with --destructive-mode. Setting useDestructiveMode: true while including gnome in extensions throws an InvalidConfigurationError with a clear message explaining why and what to do instead.
• Wayland is enabled by default for core24. Set allowNativeWayland: false to disable (sets DISABLE_WAYLAND=1).
• organize mappings are auto-generated at build time from the actual app directory, so helper binaries land under app/ inside the snap regardless of what Electron ships.
• Remote build support (Launchpad) for multi-arch without native hardware.

---

Implementation changes

The old monolithic snap.ts (396 lines) is gone. In its place:

File	Purpose
snap/SnapTarget.ts	SnapTarget (the build entry point) + abstract SnapCore<T>
snap/coreLegacy.ts	core18/20/22 — same behavior as the old snap.ts
snap/core24.ts	core24 — new GNOME extension path, organize mapping, content snap plugs
snap/coreCustom.ts	pass-through for custom snapcraft.yaml
snap/snapcraftBuilder.ts	snapcraft CLI invocation (pack, remote-build, LXD, Multipass, destructive mode)
snap/snapcraft.d.ts	TypeScript types for the snapcraft.yaml schema

LinuxTargetHelper.getSnapCore() reads snapcraft.base and returns the right implementation.

---

Tests

A new test-snap (core*) matrix job replaces the previous test-linux-native stub (which was if: false). It runs four parallel jobs, one per core:

• core18, core20, core22 — Docker image built on ghcr.io/canonical/snapcraft:7_core22 (Snapcraft 7 / Jammy)
• core24 — Docker image built on ghcr.io/canonical/snapcraft:8_core24 (Snapcraft 8 / Noble)

Both use --destructive-mode + SNAPCRAFT_BUILD_ENVIRONMENT=host so no LXD or Multipass daemon is required in CI.

The snapHeavyTest.ts suite also has install+launch tests (extract with unsquashfs, assert snap structure, run binary with --version) that run on native Linux CI runners with squashfs-tools available, skipped inside Docker.

The existing snapTest.ts unit tests still run and cover all the descriptor-level assertions (plugs, slots, extensions, compression, etc.) through snapshot testing.

---

Breaking changes

None for snap users. The snapcraft key is additive.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4cf7bb8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 10 packages

Name	Type
app-builder-lib	Major
builder-util	Major
dmg-builder	Major
electron-builder-squirrel-windows	Major
electron-builder	Major
electron-forge-maker-appimage	Major
electron-forge-maker-nsis-web	Major
electron-forge-maker-nsis	Major
electron-forge-maker-snap	Major
electron-publish	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request

[kenvandine]

I am really happy to see this being worked on, thanks so much for this.

I would like to see it made clear that destructive mode should be discouraged, but available in cases where you can't use lxd or mulitpass. For example, destructive mode should never be used when building locally and in general it's difficult to trust the resulting build even in a docker container.

[mmaietta]

@kenvandine Great callout. I wonder on what's the best way to approach this then.

Practically/ideally, we should have a destructive-mode available for the functional tests that can be run from other OS's => docker container. The e2e test is run on a native linux runner, so maybe we could test a configuration matrix?

destructive mode should never be used when building locally, and in general, it's difficult to trust the resulting build even in a docker container.

Definitely should call that out with the tsdoc guidance w.r.t. destructive mode though. That being said, we could also theoretically mark it as @private to prevent it from being documented or completely remove the field/property entirely - leaving behind a skeleton to still be able to run my test suite in the Docker container.

[kenvandine]

I think leaving the option is useful, just document is as not recommended. There are cases where people need it, but I think that's pretty rare.