Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Install precompiled extensions from GitHub release assets

Ouverte
  • Quelque chose ne va pas ?
#797 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
github, node.js, typescript
Domaine
cli, developer-experience

Piste de recherche

Start with src/extension/installer.ts to follow the current GitHub install flow and entrypoint lookup; read the extension RFC at #222 for the related open question. Then trace how extensions are registered and upgraded, and check the existing cross-spawn usage before evaluating release downloads and archive extraction. Done means installing a GitHub release asset selects a matching platform asset, extracts it when needed, finds and registers the executable, and supports the proposed release source for upgrades.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

tracking

Summary

Let elastic extension install owner/repo install a precompiled extension from the repository's GitHub release assets: detect the OS and CPU architecture, download the matching asset, extract it if it is an archive, and register the executable. This would be a deliberately small, naive version of what gh and mise's GitHub backend already do.

Motivation

Today a GitHub install does a shallow clone, then npm install --production --ignore-scripts if there is a package.json, and looks for an entrypoint in package.json bin or an executable named elastic-<name> in the root, bin/, or dist/ (src/extension/installer.ts). With no build step and --ignore-scripts, a compiled extension (Rust, Go, Zig, …) has only two options: commit binaries for every platform to the repo, or ask users to download a release asset by hand and run elastic extension create <name> --path <dir>.

I hit this while building a Rust extension. The extension contract (spawn an executable, pass the context in ELASTIC_* env vars) is language-agnostic, so the install path is the only part that assumes Node or committed files.

The RFC left this open: "Is there a preference for a compiled binary convention vs. allowing script-based extensions (like gh supports both)?" (#222, open question 4).

Proposal

When a GitHub install finds no entrypoint after cloning (or, alternatively, before cloning, when the latest release has matching assets):

  1. Fetch the release: GET /repos/{owner}/{repo}/releases/latest, or a specific tag via owner/[email protected].
  2. Pick an asset:
    • Fast path, the gh convention: an asset named exactly elastic-<name>-<os>-<arch>[.exe]. gh uses gh-<name>-<os>-<arch>[.exe], e.g. gh-whoami-windows-amd64.exe and gh-whoami-linux-386.
    • Fallback, a naive mise-style score: tokenize asset names and prefer ones that match OS aliases (process.platform: linux; darwin ~ macos/apple; win32 ~ windows) and arch aliases (process.arch: x64 ~ amd64/x86_64; arm64 ~ aarch64), and a supported archive format. On Linux, optionally prefer gnu over musl (mise also scores the C library).
    • Skip checksum/signature files (*.sha256, SHA256SUMS, *.sig). Fail with the candidate list if nothing matches or there is a tie.
  3. Download into ~/.elastic/extensions/elastic-<name>/. Release asset downloads redirect to another host, so this cannot reuse redirect: 'error' from search.ts. Allow redirects for the asset URL only, without forwarding the GitHub token.
  4. Extract .tar.gz/.tgz/.zip if needed. The CLI's runtime dependencies currently include no archive library, so either add a small one or shell out to a system tar/unzip with an explicit argv, like the existing cross-spawn usage. A bare binary needs no extraction.
  5. Find the entrypoint: an executable named elastic-<name>[.exe] anywhere in the extracted tree. chmod +x on POSIX. Keep the existing realpath containment check.
  6. Verify (optional): if the release has a SHA256SUMS-style file, check the downloaded asset against it.
  7. Register as today, and record the release tag and source so elastic extension upgrade <name> can compare against the latest release instead of pulling.

Non-goals, to keep it lightweight: version ranges, multiple binaries per extension, build-from-source fallback, signature/provenance verification, and non-GitHub hosts.

Alternatives

  • npm platform packages (optionalDependencies per OS/CPU, with a JS shim): works with the existing npm: source, but every native extension has to publish N+1 npm packages and still depends on Node at runtime.
  • Committed binaries: works today with no CLI changes, but bloats the repo and needs a per-platform launcher.

Related

  • #222 (extension RFC, open question 4)
  • #795 (--help is not passed to extensions), found while building the same extension

authored by Pi Coding Agent (Claude Opus 4)

Langage dominant
TypeScript
Étoiles
51
Forks
27
Merge moyen
1 j 19 min
PR mergées (30 j)
50

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de elastic/cli

Toutes les issues de elastic/cli

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.