النشر من سطر الأوامر

El CLI hace lo mismo que el panel —crear la versión, subir los archivos, publicarlos— sin abrir el navegador. Es lo que conviene usar en cuanto publicas más de una vez.

Necesita Node.js 20 o superior (node --version) y no arrastra ninguna dependencia: sólo la biblioteca estándar.

Instalar#

Está publicado en npm (desde el 16 de agosto de 2026):

npm install -g @fulgeon/cli
fulgeon --help

O sin instalar nada, que es lo normal dentro de un CI:

npx --yes @fulgeon/cli@1 publish --app mi-app --version 1.2.0 ...

Y si tu CI es GitHub Actions, ni eso: hay una acción oficial que instala el CLI, crea la versión, sube los archivos con sus hashes y publica. Un paso:

- uses: JaviHG/fulgeon-publish-action@v1
  with:
    token: ${{ secrets.FULGEON_TOKEN }}
    app: mi-app
    version: 1.2.0
    changelog: "@CHANGELOG.md"
    files: |
      dist/*.dmg
      dist/*.exe

Los destinos (macOS, Windows, arm64…) se deducen del nombre de cada archivo, y dry-run: "true" enseña qué haría sin tocar nada. La clave de API se crea en tu panel, en «Claves de API», y se guarda como secreto del repositorio.

Entrar#

fulgeon login

Pide la clave sin enseñarla mientras la escribes, la comprueba contra el servidor y sólo entonces la guarda en ~/.config/fulgeon/config.json con permisos 0600. Guardar sin validar sería regalarte un fallo dentro de tres semanas, en mitad de una publicación y con la culpa puesta en el sitio equivocado.

También la acepta por tubería o por bandera:

echo "$MI_CLAVE" | fulgeon login
fulgeon login --token flg_...      # ojo: queda en el historial del shell

La clave sale de claves de API. Empieza por flg_, se enseña una sola vez y conviene atarla a una sola aplicación.

Los comandos de alrededor:

De fulgeon apps la columna que importa es slug: es lo que se le pasa a --app.

Publicar#

fulgeon publish \
  --app mi-app \
  --version 1.2.0 \
  --changelog @CHANGELOG-1.2.0.md \
  --file 'dist/*.dmg' \
  --file 'dist/*.exe'

Las banderas#

Y las que entiende cualquier comando: --json, --plain, --no-color, --api <url> y --help.

Los destinos, y la trampa del --target#

Anfitriones válidos: macos, windows, linux, web, android, ios, chrome, firefox, vscode, obsidian, wordpress, minecraft-java. La arquitectura es opcional y se normaliza sola (x64, amd64 y x86-64 son x86_64; aarch64 es arm64).

Sin --target, el CLI deduce el destino: .dmg y .pkg son macOS; .exe y .msi, Windows; .deb, .rpm y .AppImage, Linux; .apk, Android; .vsix, VS Code. Cuando la extensión no decide —un .zip— lee el nombre buscando mac, win, linux, arm64, x64… y si aun así no lo sabe, se para y te pide --target en vez de adivinar. Lo deducido se enseña siempre antes de subir nada, y --dry-run lo marca explícitamente.

Cuidado con esto: un --target explícito se aplica a TODOS los archivos de esa llamada. En un lanzamiento multiplataforma conviene nombrar bien los binarios y dejar que lo deduzca.

Qué hace, paso a paso#

1. Abre la sesión. Sin clave no sigue, ni siquiera en --dry-run: un ensayo tiene que fallar por lo mismo que fallaría de verdad, o no sirve de ensayo.
2. Comprueba en local todo lo comprobable: que los archivos existan, que la extensión valga, que ninguno pase de 500 MB, que el changelog llegue a diez caracteres, que el canal exista, que los destinos sean válidos. Enterarte de que las notas son cortas después de subir 400 MB es exactamente el tipo de cosa que hace que la gente odie una herramienta.
3. Pregunta quién eres y comprueba dos cosas: que la clave tenga el ámbito publish y que la cuenta tenga aceptada la versión vigente de las condiciones de la plataforma. Lo segundo se mira aquí a propósito: el servidor lo exigiría igual, pero con el binario ya a medio subir. Si faltan, el CLI se para y te da el enlace al texto y el comando exacto para aceptarlas una vez (POST /api/v1/terms/accept).
4. Busca la ficha por id, slug o nombre, y comprueba que la clave no esté atada a otra aplicación.
5. Crea la versión, en borrador.
6. Sube los archivos, uno a uno, con una barra de progreso que cuenta los bytes que han salido de verdad.
7. Publica la versión. Y si la ficha seguía en borrador, publica también la ficha: una versión que no ve nadie no es una publicación. Si la ficha estaba retirada a propósito, no la resucita — avisa y no falla.

El orden crear → subir → publicar es deliberado. Si algo revienta a mitad, lo que queda es un borrador —un estado del que se sale— y nunca algo publicado a medias. El CLI te dice cuántos archivos llegaron a subirse antes del fallo.

La salida#

En un terminal: colores, un giro mientras trabaja, barra de progreso con bytes y velocidad, y un ✓ por paso terminado.

  ◈ fulgeon cli 1.0.0

  ✓ Clipio · clipio · as javi
  ✓ Version 1.2.0 created
  ✓ Clipio-1.2.0.dmg  12.4 MB  uploaded
  ✓ Published

    https://fulgeon.com/apps/app/clipio

Cuando no hay terminal —un CI, una tubería, > publicacion.log— no hay ni colores ni animación: una línea plana por evento, con su estado delante.

info fulgeon cli 1.0.0
ok Clipio · clipio · as javi
ok Version 1.2.0 created
version_id v_9fA2...
info upload start Clipio-1.2.0.dmg 13012345 bytes
info upload Clipio-1.2.0.dmg 50%
ok upload Clipio-1.2.0.dmg 13012345 bytes uploaded in 12.4s
ok Published
url https://fulgeon.com/apps/app/clipio

Es así para poder pasarle un grep: la URL se saca con grep '^url ' publicacion.log | cut -d' ' -f2. Los errores y las pistas van a stderr (error …, detail …, hint …), así que redirigir la salida deja el registro limpio y sigue enseñando los fallos por pantalla.

Con --json no imprime nada hasta el final, y luego un solo objeto:

{
  "ok": true,
  "app": "clipio",
  "version": "1.2.0",
  "version_id": "v_9fA2...",
  "artifacts": [
    {
      "file": "Clipio-1.2.0.dmg",
      "size_bytes": 13012345,
      "sha256": "9f2c...",
      "id": "art_3mF8...",
      "targets": [{"host": "macos", "arch": "arm64"}]
    }
  ],
  "published": true,
  "url": "https://fulgeon.com/apps/app/clipio"
}

El ensayo#

--dry-run comprueba la clave, encuentra la app y enseña la tabla de lo que subiría, marcando qué destinos ha deducido del nombre. No crea nada. Que un ensayo pase significa que la ejecución de verdad llegará al menos hasta empezar a subir.

Códigos de salida#

Variables de entorno#

Lo que el CLI no hace#

• Las subidas no se reanudan. Si se corta, queda un borrador: se termina desde el panel, o se borra el borrador y se relanza. Reanudar exige un estado de sesión en el servidor que hoy no existe, y fingir lo contrario sería peor que decirlo.
• No entiende proxies. HTTPS_PROXY se ignora.