All free skills / Other majors
app-builder-lib 26.x
Practical app-builder-lib ^26.0.0 API guidance for programmatic use, with runnable checks for architecture and platform helpers and cautions about packaging-only APIs.
- For
app-builder-lib@26.15.3- Verified
- 2026-09-08, 2 examples executed
- Skill package
@modootoday/pmcp-app-builder-lib@26.0.0
Use this skill for free
No PMCP login or subscription is required. Download the original instructions, or install the content-only archive with your project's package manager.
Download SKILL.md · Download package archive
npm install --save-dev https://pmcp.build/skills/app-builder-lib/26/package.tgz
PMCP discovers the installed package's instructions. Connect your runtime after installation.
Archive integrity
sha512-dorG1MzwfogrQiOv2+8ouP1UBE8OGqQqJEE3eCGz9oUK/Svu4wLRUqDSALHh6kwKNCCu31oY4pcYNELSjYN4fw==Complete instructions
Verified against app-builder-lib@26.15.3 on 2026-09-08. 2 of 2 examples executed.
app-builder-lib (^26.0.0)
app-builder-lib is the library layer used by electron-builder. The ^26.0.0 range means the v26 API line, including later 26.x releases; do not assume behavior is limited to 26.0.0.
Directly usable helpers
The simplest standalone surface is the architecture and platform API.
import assert from "node:assert/strict";
import { Arch, archFromString } from "app-builder-lib";
assert.equal(Arch.ia32, 0);
assert.equal(Arch.x64, 1);
assert.equal(Arch.armv7l, 2);
assert.equal(Arch.arm64, 3);
assert.equal(Arch.universal, 4);
assert.equal(archFromString("ia32"), Arch.ia32);
assert.equal(archFromString("x64"), Arch.x64);
assert.equal(archFromString("armv7l"), Arch.armv7l);
assert.equal(archFromString("arm64"), Arch.arm64);
assert.equal(archFromString("universal"), Arch.universal);
Platform provides predefined Linux, macOS, and Windows values, conversion from a platform name, the current platform, and target-map construction. Use the predefined values or Platform.fromString() rather than recreating platform instances unnecessarily. A common shape mistake is assuming that the Windows platform's string form is "win"; Platform.fromString("win") accepts that name, but Platform.WINDOWS.toString() returns "windows".
import assert from "node:assert/strict";
import { Arch, Platform } from "app-builder-lib";
assert.equal(Platform.fromString("linux"), Platform.LINUX);
assert.equal(Platform.fromString("mac"), Platform.MAC);
assert.equal(Platform.fromString("win"), Platform.WINDOWS);
assert.equal(Platform.LINUX.toString(), "linux");
assert.equal(Platform.MAC.toString(), "mac");
assert.equal(Platform.WINDOWS.toString(), "windows");
assert.ok([Platform.LINUX, Platform.MAC, Platform.WINDOWS].includes(Platform.current()));
const targets = Platform.LINUX.createTarget(undefined, Arch.x64);
assert.ok(targets instanceof Map);
assert.ok(targets.has(Platform.LINUX));
assert.deepEqual(targets.get(Platform.LINUX)?.get(Arch.x64), []);
Platform.createTarget(type?, ...archs) returns a Map<Platform, Map<Arch, string[]>>. Its first argument may be a target type, a target-type array, or null; architecture arguments select architectures for the target map.
Programmatic packaging API
The exported functions include:
build(options, packager?), returningPromise<string[]>.buildForge(forgeOptions, options), returningPromise<string[]>.checkBuildRequestOptions.combineSignResultsandisSignResultSigned.getArchSuffix.
The public classes include Packager, PlatformPackager, Target, AppInfo, CancellationToken, PublishManager, platform-specific packagers, and signing managers. new Packager(options, cancellationToken?) and the packager's build(repositoryInfo?) are documented programmatic entry points. PackagerOptions can include configuration, projectDir, targets, prepackaged, and platform target arrays.
These APIs are not ordinary pure helpers: packaging requires a build context, project/application inputs, output directories, targets, and often downloaded or cached toolsets. A plain script with no filesystem, network, project, or tool-runner setup cannot execute a real packaging build. Do not use describe, it, expect, or CLI-only configuration syntax in a direct script.
Target is an abstract build participant. Its build(appOutDir, arch) method is implemented by concrete target packages; it is not a general-purpose standalone installer function. Platform packagers likewise receive build context, and hooks receive a PlatformPackager, not merely a filesystem path.
v26-specific cautions
- Publishing files were refactored to
electron-publishin 26.0.0. Code that assumes publishing internals live in their older locations is stale. - In 26.0.1, non-external
ObjectMapshapes changed toRecord. Prefer the current typed configuration shape rather than copying an older major'sObjectMapdeclarations. - Squirrel.Windows changed implementation in 26.0.3 to use
electron-winstallerinstead of the package's former self-contained implementation. - Windows signing changed in 26.0.7: the vendor directory is signed instead of using Squirrel.Windows' signing method.
- Parallel packaging of architectures and targets became configurable with the
concurrencyconfiguration property in 26.0.13. - TypeScript configuration loading uses
jitifrom 26.4.1. Electron download handling moved to@electron/getin 26.10.0. ^26.0.0can resolve any later 26.x release, so account for these later-v26 changes when diagnosing behavior.
What this skill does not cover
This skill does not specify the full Configuration, target-specific option, signing, publishing, Forge, hook, toolset, or platform-packager contracts beyond identifying their public existence. It does not provide a runnable packaging example because the supplied research requires project files, build context, toolsets, and potentially downloads, which are unavailable to the required filesystem-free, network-free example runner. It also does not cover CLI invocation syntax or behavior outside the documented programmatic API.