Functions

f
apply(
plan: InstallPlan,
deps?: InstallDeps
): Promise<string[]>

Downloads the release archive, verifies it against the release's checksums.txt, and replaces the running binary (and its esbuild sidecar, when the install has one).

f
extract(
archivePath: string,
destination: string
): Promise<void>

Unpacks a release archive with the host's tar / unzip, falling back to PowerShell's Expand-Archive where a Windows shell has no unzip — the same two-step jsr/cli.ts uses, for the same reason: no JS extractor has to ship inside the binary.

f
swapBinary(
staged: string,
target: string,
platform?: NodeJS.Platform
): Promise<void>

Puts staged at target, honouring the one platform rule that matters: POSIX replaces a running executable with an atomic rename (the running process keeps its inode), while Windows cannot unlink a running image at all — so the old file is renamed aside first, and renamed back if anything goes wrong.

Interfaces

I
InstallDeps

The seams apply reaches the world through. All three default to the real thing.

I
InstallPlan

What to install, and over what.

Variables

v
AssetMissing: Failure.FailureFactory<"UpgradeAssetMissing", { asset: string; tag: string; }>

The release has no asset for this platform — a deno compile build asking for a target only the SEA matrix publishes, or the reverse.

v
ChecksumMismatch: Failure.FailureFactory<
"UpgradeChecksumMismatch",
{ asset: string; expected: string; actual: string; }
>

The downloaded bytes do not hash to what the release published — a corrupted or truncated transfer, or a tampered asset. Nothing has been replaced when this is thrown.

v
ChecksumsMissing: Failure.FailureFactory<"UpgradeChecksumsMissing", { tag: string; }>

The release publishes no checksums.txt, so the download cannot be verified. Refused rather than downgraded to a warning: an unverified binary replacing the one you are running is exactly the thing worth refusing.

v
DownloadFailed: Failure.FailureFactory<"UpgradeDownloadFailed", { url: string; reason: string; }>

The download itself failed — an HTTP error or a dead connection mid-transfer.

v
ReplaceFailed: Failure.FailureFactory<
"UpgradeReplaceFailed",
{ target: string; reason: string; recovered?: string; }
>

The replace itself failed, after the new binary was downloaded and verified. Carries the recovery path when the old binary had to be moved aside first.

v
TargetNotWritable: Failure.FailureFactory<"UpgradeTargetNotWritable", { dir: string; }>

The directory holding the binary is not writable by this user — the usual case being a root-owned prefix such as /usr/local/bin.