Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Install precompiled extensions from GitHub release assets

Abierto
  • ¿Algo no está bien?
#797 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github, node.js, typescript
Área
cli, developer-experience

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)

Lenguaje dominante
TypeScript
Estrellas
51
Forks
27
Merge medio
22 h 48 min
PR fusionados (30 d)
48

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de elastic/cli

Todos los issues de elastic/cli

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.