Reflexionando sobre las mejoras y cambios en el ecosistema para desarrolladores de Electron en 2023.
¡En los últimos meses, hemos estado cocinando algunos cambios en el ecosistema de Electron para sobrecargar la experiencia de desarrollador para aplicaciones de Electron! Aquí hay un breve resumen de las últimas adiciones directamente de Electron HQ.
Electron Forge 7 y más allá
Electron Forge 7 — la versión más reciente de nuestra herramienta todo en uno para empacar y distribuir aplicaciones de Electron — ya está disponible.
Mientras Forge 6 fue una reescritura completa de v5, v7 es más pequeña en alcance, pero aún contiene algunos cambios de ruptura. Siguiendo adelante, continuaremos publicando versiones importantes de Forge a medida que se necesite realizar cambios relevantes.
Para más detalles, vea el listado completo de cambios de Forge v7.0.0 en GitHub.
Cambios notables
- Se ha cambiado a
notarytool para la notarización de macOS: En 2023-11-01, Apple puso fin a la altool heredada para la notarización de macOS y este lanzamiento la elimina de Electron Forge completamente.
- Versión mínima de Node.js aumentada a v16.4.0: Con este lanzamiento, hemos establecido la versión mínima requerida de Node.js a 16.4.0.
- Se ha eliminado el soporte para
electron-prebuilt y electron-prebuilt-compile: electron-prebuilt era el nombre original para el módulo npm de Electron, pero se ha reemplazado por electron en v1.3.1. electron-prebuilt-console era una alternativa a ese binario que viene con características DX mejoradas, pero eventualmente fue abandonado como proyecto.
Highlights
- Editor de Google Cloud Storage: ¡Como parte de nuestro compromiso de mejorar el soporte de la actualización automática estática, Electron Forge ahora soporta la publicación directa a Google Cloud Storage!
- Soporte para ESM forge.config.js: Electron Forge ahora soporta los archivos
forge.config.js. (P.D. Esperamos el soporte de puntos de entrada ESM en Electron 28.)
- Makers ahora se ejecutan en paralelo: En Electron Forge 6, Makers se ejecutó secuencialmente para el ✨ legado ✨. Desde entonces, hemos probado paralelización para el paso de hacer sin efectos secundarios adversos, ¡así que deberías ver una aceleración al construir múltiples objetivos para la misma plataforma!
🙇 Gran gracias a mahnunchik por las contribuciones tanto para el editor GCS como para soporte ESM en configuraciones de Forge!
Mejor soporte estático y actualizaciones automáticas
Squirrel.Windows y Squirrel.Mac son tecnologías actualizadoras específicas de la plataforma que respaldan el módulo autoUpdater integrado de Electron. Ambos proyectos soportan actualizaciones automáticas mediante dos métodos:
- Un servidor de actualizaciones compatible con Squirrel
- Una URL de manifiesto alojada en un proveedor de almacenamiento estático (por ejemplo, AWS, Google Cloud Platform, Microsoft Azure, etc.)
El método de actualización del servidor ha sido tradicionalmente el método recomendado para las aplicaciones Electron (y proporciona personalización adicional de la lógica de actualización), pero tiene un lado inferior importante — requiere que las aplicaciones mantengan su propia instancia del servidor si son de código cerrado.
Por otra parte, el método de almacenamiento estático siempre ha sido posible, pero fue indocumentado dentro de Electron y mal soportado en los paquetes de herramientas de Electron.
Con un gran trabajo de @MarshallOfSound, la historia de actualizaciones para actualizaciones automáticas de aplicaciones sin servidor se ha simplificado drásticamente:
- Los creadores Zip y Squirrel.Windows de Electron Forge ahora pueden configurarse para mostrar los manifiestos de actualización compatibles con
autoUpdater.
- Una nueva versión principal de
update-electron-app (v2.0.0) ahora puede leer estos manifiestos generados como una alternativa al servidor update.electronjs.org.
Una vez que sus Makers y Publishers estén configurados para cargar manifiestos de actualización a la nube de almacenamiento de archivos, puede habilitar actualizaciones automáticas con sólo unas pocas líneas de configuración:
const { updateElectronApp, UpdateSourceType } = require('update-electron-app');
updateElectronApp({
updateSource: {
type: UpdateSourceType.StaticStorage,
baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
},
});
El universo extendido @electron/
Cuando Electron comenzó por primera vez, la comunidad publicó muchos paquetes para mejorar la experiencia de desarrollar, empaquetar y distribuir aplicaciones de Electron. Con el tiempo, muchos de estos paquetes fueron incorporados a la organización GitHub de Electron, y el equipo central asumió la carga de mantenimiento.
En 2022, comenzamos a unificar todas estas herramientas de primer partido bajo el nombre de @electron/ en npm. Este cambio significa que los paquetes que solían ser electron-foo ahora son @electron/foo en npm, y los repositorios que antes se llamaban electron/electron-foo ahora son electron/foo en GitHub. Estos cambios ayudan claramente a fomentar proyectos de primera parte a partir de proyectos de tierras de usuario. Esto incluye muchos paquetes comúnmente usados, como:
@electron/asar@electron/fuses@electron/get@electron/notarize@electron/osx-sign@electron/packager@electron/rebuild@electron/remote@electron/symbolicate-mac@electron/universal
Siguiendo adelante, todos los paquetes de la primera parte que liberemos también estarán en el espacio de nombre de @electron/. Hay dos excepciones a esta regla:
- El núcleo de Electron continuará publicándose bajo el paquete
electron.
- Electron Forge continuará publicando todos sus paquetes monorepo bajo el espacio de nombre de
@electron-forge/.
⭐ Durante este proceso, también tomamos accidentalmente el repositorio electron/packager privado, que tiene el desafortunado efecto secundario de borrar nuestro contador de estrellas de GitHub (más de 9000 antes de la borrada). Si eres un usuario activo del paquete, apreciaríamos una ⭐ Estrella ⭐!
Presentando @electron/windows-sign
A partir de 2023-06-01, los estándares de la industria comenzaron a requerir que las claves para que los certificados de firma de código de Windows se almacenaran en hardware compatible con FIPS.
En la práctica, esto significó que la firma de código se volvió mucho más difícil para las aplicaciones que construyen y firman en entornos IC, ya que muchas herramientas de Electron toman un archivo de certificado y contraseña como parámetros de configuración e intentan firmar desde allí usando lógica codificada.
Esta situación ha sido un punto de dolor común para los desarrolladores de Electron que es la razón por la que hemos estado trabajando en una mejor solución que aísla la firma de código de Windows en su propio paso independiente, similar a lo que @electron/osx-sign hace en macOS.
En el futuro, planeamos integrar plenamente este paquete en la cadena de herramientas Electron Forge, pero actualmente vive por su cuenta. El paquete está actualmente disponible para la instalación en npm install --save-dev @electron/windows-sign y puede usarse programáticamente o a través de CLI.
¡Inténtalo y danos tu opinión en el seguimiento de incidencias del repositorio!
¿Qué sigue?
Estaremos entrando en nuestro período anual de silencio de diciembre el mes que viene. Mientras lo hacemos, estaremos pensando en cómo podemos mejorar aún más la experiencia de desarrollo de Electron en 2024.
¿Hay algo que te gustaría ver trabajar en el futuro? ¡Déjanos saber!