+100, eso sería muy útil para reducir el tamaño de la aplicación.

¿Se puede cambiar la extensión .asar ? Suena muy raro en húngaro. Básicamente significaría the shit en el mal sentido ( enlace ).

.apak? con toda seriedad, hay toneladas de idiomas, por lo que casi cualquier extensión puede sonar rara en algunos de ellos.

La instalación y actualización del tiempo de ejecución de IMO debe ser lo más fácil posible. Muchos tiempos de ejecución tienen notificaciones muy molestas. Además, si va a hacer esto, se deben proporcionar algunos metadatos de manifiesto adicionales, ya que es posible que las versiones más nuevas de la aplicación no funcionen en el tiempo de ejecución anterior, por lo que debe comparar la versión actual del tiempo de ejecución con la versión en el manifiesto de la aplicación (posiblemente incluso las versiones varían como en el nodo packages ), y luego, si es necesario actualizar el tiempo de ejecución, haga que este proceso sea lo más fácil posible. No sé qué es fácil para la mayoría de la gente, pero para mí es solo una ventana con una barra de progreso o mensajes de estado ("Descargando... 57%", "Actualizando...")
No estoy seguro, pero también se pueden considerar actualizaciones en segundo plano. Puede ser algún servicio de actualización o simplemente una descarga en tiempo de ejecución mientras la aplicación se está ejecutando y se actualiza cuando la aplicación se cierra.

+1 por esto. Estoy trabajando en una aplicación que tengo que entregar para mac y windows, y esto simplificaría considerablemente la entrega.

¡Esto sería genial!

Algunos pensamientos:

• Como dijo @YuriSolovyov , necesitamos una forma de declarar con qué versiones del atom-runtime es compatible un asar en particular. Preferiblemente, esto también debería permitir especificar una versión exacta, ya que esto reduce la carga del control de calidad al lanzar una aplicación basada en asar.
  
  
  
  • Para respaldar eso, necesitaríamos permitir tener múltiples versiones del atom-runtime instaladas una al lado de la otra, potencialmente invisibles para el usuario.
  
  
  • Tenga en cuenta que esto está algo en desacuerdo con los ideales de limitar el tamaño de las descargas. Sin embargo, una empresa que produzca varios productos basados ​​en asar podría estandarizarse internamente para que todas sus aplicaciones sigan usando la misma versión.
  
  
• No mencionaste el soporte para la actualización automática de atom-runtime en Mac, pero eso sería _muy_ útil.
• En lugar de tener instalaciones solo de fuente en Linux, sería bueno admitir la instalación/actualización de archivos binarios, tanto a través de paquetes .deb/.rpm como con algún método que no requiera derechos de sudo para instalar (es decir, por usuario). Para tiempos de ejecución instalados por usuario, la actualización automática también sería muy útil.
• ¿Habría algún soporte para mantener actualizados los archivos asar instalados, o es algo que tendría que implementarse de forma independiente en cada aplicación?

Por último, ¿cuál es el cronograma de este esfuerzo? ¿Cuál sería la mejor manera de comenzar, si quisiera comenzar a implementar partes de esto? Estoy abierto a contribuir.

@ joshuawarner32 Actualmente, esta es solo una idea aproximada, planeo trabajar en ella después de resolver algunos problemas importantes de Atom-Shell, pero podría ser meses después.

Creo que también vale la pena mirar los tiempos de ejecución existentes y cómo están funcionando/actualizados, qué tan perturbadores son y qué otros pros y contras.

Actualmente, esta es solo una idea aproximada, planeo trabajar en ella después de resolver algunos problemas importantes de Atom-Shell, pero podría ser meses después.

Han pasado unos 5-6 meses. Sería genial tener esto implementado.

Hemos creado una implementación interna de esto que se adapta muy bien a nuestro caso de uso particular, y es posible que podamos actualizarlo. El peligro sería que en realidad es demasiado específico para nuestro caso de uso, y nadie más estaría interesado en la complejidad adicional.

Estos son los aspectos más destacados de nuestro diseño:

• Implemente archivos .asar.gz para varias aplicaciones diferentes en un servidor
• Distribuya una compilación única de atom-shell a los usuarios, que no incluye ningún código para aplicaciones específicas
• Al iniciar la aplicación, descargue el archivo .asar.gz apropiado (si no está allí o si hay uno más reciente en el servidor). Extráigalo y ejecute la aplicación contenida.
• Nuestra compilación atom-shell acepta un argumento --app para especificar qué aplicación descargar/ejecutar

¿Es eso lo que la gente del caparazón atómico tenía en mente? ¿Sería algo así útil para otras personas?

Al igual que el JRE, podría ser el ERE (entorno de tiempo de ejecución de electrones), con archivos .eapp (aplicación de electrones)

-1 para .eapp

+1 ¡Lo necesito!

En Windows, podemos proporcionar un instalador y un actualizador automático para atom-runtime, y registrar el tipo de archivo .asar que se abrirá con él.

Instale Steam en Windows y compruebe cómo crean accesos directos a los juegos. De hecho, usan un controlador de protocolo, es relativamente inteligente.

:+1: en el modelo Steam.

No hay ningún obstáculo técnico para implementar esto, todo puede ser una aplicación de Electron en sí misma. Pero el problema es que tampoco es fácil de implementar, teniendo en cuenta todos los detalles, creo que requiere un pequeño equipo trabajando a tiempo completo en ello, no estoy seguro de si alguna vez sucederá.

Pero el problema es que tampoco es fácil de implementar, teniendo en cuenta todos los detalles, creo que requiere un pequeño equipo trabajando a tiempo completo en ello, no estoy seguro de si alguna vez sucederá.

Hay muchas preguntas en mi mente que, si bien ciertamente no son insuperables, hacen que este plan sea Difícil. Por ejemplo, digamos que la "Aplicación 1" requiere 0.30.x y no puede ejecutarse en 0.31.x, y la "Aplicación 2" requiere lo contrario. ¿Quién gana en este escenario?

Parece mucho esfuerzo e infraestructura/engaños para optimizar algo que no es nuestro mayor problema: espacio en disco y ancho de banda, a expensas de la complejidad del desarrollador (es decir, ahora los desarrolladores tienen que crear este loco instalador en cadena para instalar/ verificar Electron, luego instalar su aplicación)

¡No quiero odiar una idea! Simplemente creo que con el tiempo que nos tomaría hacer esto, podríamos gastarlo en nuestro gran problema: hacer que sea muy fácil para los nuevos desarrolladores crear y publicar aplicaciones de Electron, desde su primera línea de código hasta el final. enviándolo a los usuarios

@paulcbetts Pero bueno, sus beneficios valen la pena, ¿no? Al actualizar una aplicación, los usuarios tendrán que descargar menos de un mb en lugar de ~70 mb. Lo que significa que ni siquiera necesitaremos marcos de actualización automática y todo, solo tendremos que descargar y extraer un archivo micro-zip con un par de archivos.

Pasé los últimos tres meses en un área remota donde la velocidad era inferior a 128 kbps y créanme, el tamaño de la actualización es un gran dolor de cabeza, la peor parte es que todavía hay muchas personas en situaciones similares.

Lo que significa que ni siquiera necesitaremos marcos de actualización automática y todo, solo tendremos que descargar y extraer un archivo micro-zip con un par de archivos.

Sin embargo, no creo que eso sea cierto, porque es casi seguro que en algún momento querrás pasar a una actualización a una versión más nueva de Electron y luego kerplowie, estás en una situación similar (o al menos uno que es igualmente feo )

Las aplicaciones básicas ahora cuestan entre 30 y 50 megas, a menos que tengas una tonelada de videos dentro de tu paquete. No creo que sea una exageración para la mayoría de la gente descargar. Creo que el video promedio de youtube es entre 30 y 40 mb...

Solo me gustaría hacer una nota aquí, en China, la velocidad de conexión promedia alrededor de 20kB/s (Concedido, tengo una conexión más lenta que ~92% de mi ciudad). Actualizar Atom/electron generalmente requiere un día completo de wget -c 'ing. a menos que se utilicen los espejos taobao.

Para la compatibilidad de versiones, el desarrollo de electrones se mueve demasiado rápido para tener una versión general, ¿quizás se podría usar algún tipo de contenedor/ayudante para usar/descargar la versión principal solicitada cuando se inicia la aplicación?

20kb/s? ¿Cómo puedes sobrevivir? ¡No puedo imaginar lo difícil que debe hacer las cosas!

@steelbrain no es mi intención

@RIAEvangelist Subiendo en los tiempos rápidos y mucha paciencia. La velocidad se vuelve muy rápida a altas horas de la noche, así que deja las descargas ejecutándose o programándolas mientras duermes. :3

De todos modos, creo que no sería demasiado trabajo escribir un contenedor (básico) de terceros, ¿alguien quiere intentarlo?

Sin embargo, los archivos .asar no pueden declarar fácilmente su versión electrónica. ¿Quizás se necesitaría otro sistema descriptor de programa?

¿Qué tal algún tipo de despachador de versión de tiempo de ejecución que (descargue si es necesario y) inicie la versión requerida de tiempo de ejecución para su aplicación? Podemos agregar una entrada a package.json para eso.

@YuriSolovyov Excepto que no podemos hacer que dicho tiempo de ejecución maneje los archivos .json de forma predeterminada. Supongo que primero podría leer el archivo asar y ver el paquete.json, pero eso lo ralentizaría un poco.

@Tribex sí, el flujo lógico es como:

-> associate .asar with runtime
-> user launches .asar app
-> dispatcher reads package.json in .asar
-> (optional) downloads required runtime version if needed
-> launches app

Idealmente, el modo de tiempo de ejecución debería funcionar como Steam o Chrome App Launcher . El problema principal es cómo manejamos las aplicaciones cuando el tiempo de ejecución se actualiza a una nueva versión.

Las aplicaciones de Electron sufren la actualización de Electron, especialmente los módulos nativos del nodo. Se requiere que los módulos nativos se reconstruyan para cada actualización de Electron debido al problema de ABI de C++ (hay varios problemas de bloqueo olvidados y reconstruidos informados por los usuarios).

Steam no sufre por el dolor ya que cada juego en Steam es un programa independiente, en realidad puedes iniciar el juego sin Steam Client. Chrome App Launch tampoco, porque las aplicaciones de Chrome están escritas en HTML/JS/CSS, que son tipos de lenguajes interpretados, no hay brechas en las diferentes versiones de Chrome.

@hokein, ¿qué tal si tenemos un "cliente" liviano en un idioma nativo, que descarga varios idiomas, cada vez que encuentra una aplicación que depende de una versión desinstalada de electron, descarga una copia y luego ejecuta cada aplicación con su electrón específico?

Hay un nuevo lanzamiento de Electron aproximadamente una vez por semana, por lo que las posibilidades de que 2 aplicaciones tengan exactamente la misma versión de Electron son escasas.

Para respaldar un enfoque de tiempo de ejecución, probablemente necesitemos comenzar a separar los lanzamientos en versiones LTS (soporte a largo plazo) y versiones de última generación. El LTS será para la producción y la vanguardia será para el desarrollo y las pruebas. LTS solo obtendrá correcciones de errores y tal vez algunos cambios que no reemplazan las versiones principales de io.js y content shell, por lo que los módulos nativos aún deberían funcionar.

dado lo que ha dicho @etiktin , a menos que un usuario tenga muchas aplicaciones electrónicas en su sistema, probablemente no habría ningún beneficio en el tiempo de descarga, ya que aún tendría que descargar el tiempo de ejecución la mayoría de las veces.

En las dos semanas que he estado mirando electron ahora, creo que he visto 4 lanzamientos.

@etiktin Idealmente, si electron sigue a semver, entonces una aplicación podría declarar la versión ^ 0.31 y usaría la última versión 0.31.x. Eso podría ayudar un poco las cosas.

Tenemos una aplicación en producción con un mecanismo de actualización automática de semver que hace lo siguiente:

1. OBTENGA un punto final HTTP simple en el servidor que proporcione la versión actual (0.3.0, 0.3.1, etc.) y la plataforma (darwin-x64, win32-ia32, win32-x64, etc.) de la aplicación.
2. El servidor devuelve "304 No modificado" o un manifiesto JSON si hay una versión más nueva.
3. El manifiesto JSON es esencialmente una lista anidada de carpetas, archivos y enlaces simbólicos en la versión más reciente.
4. Una entrada de carpeta en el manifiesto JSON tiene este aspecto: [nombre, matriz de entradas secundarias].
5. Una entrada de archivo en el manifiesto JSON tiene este aspecto: [nombre, hash de contenido, conjunto de hash de contenido dividido en fragmentos de 64 KB, un indicador de número entero que indica si el archivo es ejecutable o no].
6. Una entrada de enlace simbólico en el manifiesto JSON tiene este aspecto: [nombre, ruta de destino].
7. Estos manifiestos JSON se crean y almacenan en caché en el servidor para cada versión. Para cada archivo en el manifiesto JSON, el servidor ejecuta un algoritmo de desduplicación simple para dividir el archivo en fragmentos de longitud variable mediante la fragmentación dependiente del contenido y, a continuación, procesa los fragmentos mediante SHA256. Esto garantiza que la mayoría de los hash de fragmentos para diferentes versiones del mismo archivo permanezcan iguales, incluso si el contenido se desplaza unos pocos bytes. La longitud promedio de los fragmentos es de aproximadamente 64 KB para lograr una deduplicación y una eficiencia de compresión óptimas. Si los fragmentos son más grandes, tampoco se deduplicarán, si los fragmentos son más pequeños, tampoco se comprimirán. La longitud promedio de fragmentos también se incrementará para archivos muy grandes para evitar tener demasiados hash de fragmentos en los metadatos.
8. Cuando la aplicación recibe un nuevo manifiesto JSON del servidor, verifica el espacio libre disponible en el disco y crea un nuevo directorio temporal con una ID única universal. Usando su antiguo manifiesto local como punto de partida, luego copia fragmentos de archivos locales o descarga fragmentos faltantes del servidor para recrear el nuevo manifiesto. Después de crear la nueva versión, verifica la estructura del directorio y las firmas de todo el contenido del archivo. Si algo se corrompió en la descarga, elimina la actualización.
9. Si la nueva actualización se verificó con éxito en el manifiesto, inicia la nueva versión de la aplicación en la nueva ruta de actualización.
10. La versión anterior nota que se está ejecutando otra versión y se apaga.
11. La nueva aplicación espera a que se cierre la versión anterior, luego se copia a sí misma en otro directorio temporal, cambia el nombre de la versión anterior a un directorio de archivo y cambia el nombre del directorio temporal a la ubicación de la versión anterior (/Aplicaciones/Ronomon.app). Luego se ejecuta de nuevo, pero ahora desde la ubicación de la versión anterior (/Applicatons/Ronomon.app) y luego limpia el directorio de archivo.
12. Si algo sale mal durante la transición, la versión anterior permanece en la ruta canónica hasta que la llamada de cambio de nombre la cambia.

En general, está funcionando muy bien en producción. La deduplicación y compresión significa que solo se necesita descargar alrededor del 33% para una actualización de versión principal típica y las actualizaciones menores requieren solo 1-2 MB, según la aplicación. La actualización automática maneja el código de Electron y la aplicación como una unidad atómica, y nunca viola ninguna firma de código en el proceso.

+1 A la idea
+1 Para renombrar asar

Vine a hacer un problema con respecto a esto. Encontré que esto ya existía, así que pondré mi + :100: a esto
Necesitamos totalmente una solución similar a JRE o .NET o Adobe Air, porque empaquetar el tiempo de ejecución con cada aplicación los hace realmente voluminosos.

¿Alguna actualización sobre tener un tiempo de ejecución separado de las aplicaciones?

¿Está cerrado porque se ha desarrollado una solución?

@PierBover este problema está abierto.

esto - https://github.com/KeitIG/museeks/issues/48 - se cerró. en el repositorio de otra persona.

Oh, gracias @championswimmer y perdón por la confusión.

Entonces, ¿hay alguna noticia sobre el tiempo de ejecución independiente? ¿Es algo en lo que se está trabajando?

@PierBover es probable que no suceda pronto debido a la fragmentación de la versión actual (es difícil encontrar aplicaciones de 2 electrones que estén usando exactamente la misma versión). Tal vez después de que se publique v1.

@jorangreef , ¿utiliza su mecanismo de actualización diferencial en todas las plataformas? Sería fantástico si pudiera publicar ese código como un módulo independiente.

@championswimmer Sí, me las arreglé para crear un script de compilación para mi aplicación, así que estoy bien para distribuir mi aplicación ahora. Pero estoy atento a esto porque sería interesante.

@etiktin Sí, la actualización automática diferencial actualmente funciona en todas las plataformas. Si también incluye un instalador mínimo que realiza la descarga, varias aplicaciones podrían compartir el instalador y usar una versión en caché de Electron si ya está disponible. Esto serviría para hacer que las instalaciones sean mucho más rápidas. Me gustaría abrirlo si la gente está interesada e intentaré publicar el código en los próximos meses.

Por ejemplo, digamos que la "Aplicación 1" requiere 0.30.x y no puede ejecutarse en 0.31.x, y la "Aplicación 2" requiere lo contrario. ¿Quién gana en este escenario?

Luego, deben instalar las dos versiones y habrá dos tiempos de ejecución, al igual que VS C ++ 2008 coexiste con 2005. Me gusta mucho cómo se instalan los tiempos de ejecución de VS C ++, el instalador instalaría una versión requerida si no hay ninguna, y otros pueden depender de más tarde, y diferentes tiempos de ejecución pueden coexistir. La aplicación de los requisitos de la versión también parece ser más fácil de hacer en el instalador.

@louy2 Hay una diferencia entre el ejemplo de Visual C++ (3 años entre lanzamientos) y Electron (3 lanzamientos por mes como mínimo)

Bromearé con una cita de 'este es un sistema roto' aquí, si la mayoría de
las aplicaciones en el ecosistema Electron no son compatibles con +- 0.0.1 o
Diferencias de versión 0.1.0

El 20 de febrero de 2016 a las 18:55, Pierre de la Martinière <
[email protected]> escribió:

@louy2 https://github.com/louy2 Hay una diferencia entre el
Ejemplo de Visual C++ (3 años entre versiones) y Electron (3 versiones por
mes por lo menos)

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/atom/electron/issues/673#issuecomment-186595285 .

+1

He empaquetado electron en un paquete .deb usando fpm . Este podría ser un buen punto de partida en Linux (basado en Debian o RPM, al menos). Puedes echar un vistazo aquí: iamale/electron-deb ; también hay una aplicación de ejemplo . (También funcionará con asar, solo necesita agregar una entrada MIME en el paquete de tiempo de ejecución).

¡Sería genial si tuviéramos algo así en las otras plataformas también! Probablemente podría intentar empaquetarlo para Windows, pero ya no lo uso activamente y realmente no tengo mucha experiencia con él.

(¡Gracias a @louy2 por señalarme este hilo!)

Por cierto, ¿cuál es el tipo MIME para .asar? ¿Serviría application/x-asar ?

@iamale En lugar de fpm , ¿ha echado un vistazo a AppImageKit ? El principal beneficio que obtiene es que, en lugar de crear múltiples bibliotecas y todo, puede apuntar a todas las distribuciones de Linux con un ejecutable. Además, ya no tiene que pedirle al usuario que instale ninguna dependencia, ya que se incluyen con el ejecutable. Es un buen proyecto, por favor échale un vistazo.

y del mimo, que tal application/x-electron ?

@steelbrain Esa es una buena idea. Sin embargo, esto no resolvería el problema original: el tiempo de ejecución de Electron tendría que empaquetarse con cada aplicación (porque las imágenes deben ser independientes), que es exactamente de lo que se trata este problema. Aunque creo que debería ser relativamente fácil hacer AppImages a partir de aplicaciones de Electron, y creo que esto sería genial cuando no se puede usar la administración de paquetes tradicional (distribuciones raras o usuarios sin privilegios). Entonces, ¡gracias por señalarlo!

application/x-electron suena muy bien por cierto, probablemente se quede con él.

¡Se agregó soporte asar! Todavía no está en el repositorio, lo reconstruiré más tarde hoy o tal vez mañana. Por ahora, puede obtener el paquete en transfer.sh (el enlace será válido durante las próximas 2 semanas)

Necesitas un asar.json dentro del .asar, para decir:

• versión recomendada
• versiones compatibles
  Una vez hecho esto, necesita una aplicación que use electron (cualquier versión) para verificar la web en busca de (1) actualizaciones para sí mismo (el verificador) y (2) las versiones existentes en su computadora, luego, si existe una versión compatible, analiza la ruta de acceso al .asar abierto; de lo contrario, descargue la versión recomendada y verifique nuevamente. La aplicación, en sí misma, se puede escribir en Electron o Python (ya que solo requeriría una interfaz de usuario mínima o nula).

La idea es: la aplicación que verifica si se descarga la versión electrónica requerida no tiene nada que ver con las versiones electrónicas necesarias.

Si surge la necesidad, puede actualizar el contenido de default_app, así como el resto de la aplicación, a excepción de ella.

Y allí, puede tener las versiones guardadas con app.setPath("userData", __dirname + "/ElectronVersions"); luego esas versiones podrían dejarse allí e instalar otras nuevas a medida que surja la necesidad.

En lugar de fpm, ¿ha echado un vistazo a AppImageKit ?

Hay una AppImage de Atom disponible en https://bintray.com/probono/AppImages/Atom/_latestVersion#files : simplemente descárguela, chmod a+x y ejecútela en cualquier distribución de Linux x86_64 que no esté demasiado desactualizada.

El problema no es solo Linux, necesitamos una forma de hacerlo entre sistemas operativos, lo que significa que debemos poder ejecutarlo en Linux, Windows y Mac OSx.

Algún tipo de iniciador específico del sistema operativo que busca si el tiempo de ejecución está disponible y actualizado/compatible con el paquete asar

(muchos años después) Permítanme resumir la discusión:

1. @zcbenz propone un tiempo de ejecución que administra las instancias locales de Electron para que los paquetes .asar solo se distribuyan y se evite la agrupación de binarios de Electron. El tiempo de ejecución gestiona también la ejecución de paquetes .asar .
2. @YurySolovyov sugiere mejorar el archivo de manifiesto con información adicional (p. ej., la versión de Electron requerida) para que el tiempo de ejecución sepa qué versión se utilizará para cada paquete .asar . Aquí se ofrece una descripción general de este enfoque.
3. @joshuawarner32 presenta la idea de múltiples versiones de tiempo de ejecución, empaquetado binario (por ejemplo, como .deb ) y actualización automática para paquetes de .asar . Además se considera la idea de un servidor de distribución.
4. @paulcbetts sugiere echar un vistazo al modelo de Steam e implementar algo similar. Señala las complicaciones vinculadas con la idea de un tiempo de ejecución local que admita diferentes versiones de Electron, etc.
5. [la gente habla sobre la velocidad de Internet en China y sus asuntos de la infancia]
6. @hokein señala las complicaciones cuando se actualiza el tiempo de ejecución. Especialmente wrt. módulos nativos que deben construirse nuevamente contra encabezados de Electron.
7. @etiktin quiere tener LTS y versiones de última generación para que las aplicaciones listas para producción usen LTS en lugar de última generación.
8. @Tribex dice que si nos ceñimos a las versiones semánticas , no necesitamos tener una instancia local de _todas_ las versiones, sino solo aquellas que son incompatibles.
9. @jorangreef proporciona un ejemplo de sistema diferencial de actualización automática que ya está en producción para su propia aplicación.
10. @iamale ha creado un paquete fpm de Electron para ejecutar paquetes de .asar .

_descargo de responsabilidad: Traté de incluir solo los puntos principales de discusión. ¡Disculpen si me perdí algo!_

Leí la discusión hasta aquí, traté de resumir los puntos principales y quería abordar algunos de ellos. La idea de un tiempo de ejecución con "integraciones profundas de plataforma" va más allá de una simple instancia local. Se debe definir un producto mínimo viable, que actúe como un tiempo de ejecución para todo el sistema. También agregué una función agradable de tener que podría ser útil. La última sección describe qué cambios/características deben implementarse.

Razón fundamental:

Lo que están haciendo la mayoría de los desarrolladores (es decir, agrupar binarios de Electron) es como vincular todas las bibliotecas compartidas de forma estática. Es como entregar un horno con cada pizza que vendemos.

JMV:

• Administrador de entorno : realiza un seguimiento de las instancias de Electron disponibles localmente. Se puede usar para decidir qué paquete es compatible con qué instancia (usando package.json mejorado [ver más abajo]). También debe encargarse de establecer las variables de entorno correctas para que se ejecuten los paquetes.
• Administrador de actualizaciones : se ha discutido la posibilidad de actualización automática (+ notificación) y actualización automática diferencial. Sería bueno tenerlo como un demonio que se encarga de actualizar las instancias locales a las últimas versiones.

Agradable tener:

• Administrador de paquetes/dependencias : al igual que apm de Atom, se necesita un administrador de paquetes para descargar paquetes de .asar (desde GitHub o una URL dada, etc.) e instalarlos localmente (comparable con apt-get en Ubuntu o brew en Mac).

Requisitos:

• Archivos de manifiesto mejorados : package.json también debe contener un semver (o rango de semver) para indicar qué versión de Electron se requiere.
• Procedimiento de instalación/desinstalación definido : ATM el paquete .asar contiene todo lo necesario para ejecutar una aplicación. Sin embargo, es posible entregar solo los módulos de dependencia de origen y descarga en la instalación. Si somos demasiado valientes, podemos tener algún tipo de directorio _global_ que contenga dependencias para todas las aplicaciones (la estructura plana de npm 3 podría ayudar). Esto, sin embargo, puede volverse muy complicado, muy rápido (por ejemplo, al desinstalar una aplicación).
• Múltiples tiempos de ejecución locales : si se ha aplicado el control de versiones semántico hasta ahora, solo hay dos versiones incompatibles 0.x y 1.x . Las versiones menores y los parches deben ser compatibles con versiones anteriores, por lo que solo necesitamos la última versión de 0.x y 1.x en el sistema.

Inspiraciones:

• Administrador de dependencias/entorno: Python's virtualenv , Ruby's rbenv , y también vea ruby-build .
• Administrador de paquetes: pip de Python, pip apm Atom.
• Administrador de actualizaciones: el proceso zygote de Chromium tiene un enfoque interesante para las actualizaciones _silenciosas en segundo plano_.
• Traductores de código (para adaptarse a las nuevas API): Pythons 2to3 .

epm (gestor de paquetes de electrones) parece que ya está tomado como nombre...
¿Tal vez llamar al tiempo de ejecución elec y las aplicaciones .tron ? Probablemente haya algunos problemas de marcas registradas con TRON, pero sonaría genial;)

Tal vez uepm (administrador universal de paquetes de electrones), ya que está destinado a ejecutarse en todos los sistemas operativos compatibles con Electron... o epmc (centro de administración de paquetes de electrones) y el archivo .epack (paquete de electrones). La extensión, al menos, suena mejor que .tron y no se puede confundir con una película ("dame esa cosa de tron, amigo" _te pasa la película_).

También hay una gran cantidad de palabras en el campo de la física teórica relacionadas con el electrón.

• fermión
• leptón
• cargar
• culombio
• pauli

Y, no relacionado directamente, pero algo más acorde a lo que está pasando con un administrador de paquetes,

• bosón
  ;)
  (creo que el fotón ya ha sido tomado)

@kapouer + quark? aunque no estoy seguro si se toma

Quark está tomado, el resto no lo sé. Pero, ¿por qué debemos mantener el statu quo, cuando esta lista de sugerencias sugiere NO mantener el statu quo? Pero ya que estamos en eso, ¿por qué no llamarlo Hauldron? Tomado del LHC. Collider no es una buena idea, le está dando un matiz negativo al producto, porque su significado está estrechamente ligado a la guerra...

Particle(s) ? Aunque bastante largo.
Lista de partículas en wiki

Si bien nombrar es importante, sigo pensando que primero debemos investigar la semántica de tiempo de ejecución/actualización/empaquetado/distribución.

lepton parece perfecto ya que es la familia de partículas a la que pertenece el electrón.

Una idea un poco fuera de alcance: un administrador de tiempo de ejecución más genérico sería aún más asombroso (y no realmente más difícil de implementar). Por ejemplo, también podríamos incluir archivos binarios de @nwjs y administrarlos en el mismo gestor de versiones (al igual que @asdf-vm, pero para tiempos de ejecución de GUI).

Rápido y sucio: https://github.com/iamale/lepton. Solo admite la versión fija por ahora (semver es lo siguiente que debe hacer), y las aplicaciones están desempaquetadas (es decir, todavía no hay .asar-s).

¡Agradable!

+1

Incluso si no hay .asar, @iamale , siempre que tenga alguna forma de saber qué archivo abrir, creo que debería estar bien. Como, por ejemplo, podría tener un file.something con un código json vinculado a package.json para que sepa qué abrir...

Esta es una idea bastante loca, pero ¿qué hay de usar el campo electron en package.json para hacer
¿algún ejecutable del paquete npm (bueno, no como CUALQUIERA, pero preparado)?
Me gusta:

electron: {
  "main": "index.js",
  "runtime": ">= 1.2"
}

Esto podría lograrse agregando la capacidad de electron para instalar paquetes npm y hacerlos ejecutables y visibles para el sistema host.
Al igual que

electron install atom

Para que esto funcione, necesitaríamos dividir el comando electron y los paquetes de tiempo de ejecución reales.

pero ¿qué hay de cambiar el nombre de package.json a package.electron y tener su contenido algo como esto?

run:{
  "name"    : "zDillinger",
  "version" : "0.0.1-1",
  "main"    : "main.js"
},
electron: {
  "recommended": "1.2",
  "compatible": [
    "1.2.1-1.2.5",
    "1.3,1.3.0.1",
    "1.1"
  ]
}

En este ejemplo, recomendaría usar electron 1.2, si no se encuentra también verifica si hay alguna versión entre 1.2.1 y 1.2.5, si no busca 1.3.1, luego 1.3.0.1, si no verifica para 1.1 y si no, descargas 1.2.

Tal vez podría haber algo como que descargue automáticamente la versión recomendada, y no puede, luego busca las versiones compatibles. Y toma todos y cada uno de los compatibles y revísalos, y si ninguno funciona, pregunta al usuario si no quiere usar una versión incompatible, y si presiona no , se ejecutaría con una versión incompatible encontrado en la PC, y si no se encuentra ninguno, en lugar de solicitar usar una versión incompatible, muestra una ventana emergente de error que dice que no se detectó ninguna instalación de Electron.

@sapioit Tener un manifiesto separado me parece una buena idea. Tener una extensión de archivo personalizada simplificaría bastante las cosas. (Aunque .electron parece un poco largo).

¿Quizás según el leptón de @iamale , .lept?

No veo ningún beneficio por no usar package.json , el campo de electrones hace la parte de aislamiento. Babel y ESlint usan esta técnica y les va bien.
Esto hace que sea mucho más fácil publicar aplicaciones directamente en/a través de npm.

Sí, secundo a @YurySolovyov : creo que ponerlo en package.json es más apropiado

@YurySolovyov La ventaja de un archivo adicional es que el tiempo de ejecución puede registrar un controlador para la extensión del archivo adicional y ejecutarse automáticamente como el abridor predeterminado del archivo. Mientras que hacer esto con package.json requeriría registrar el controlador para cada archivo JSON, lo que sería una molestia para los usuarios.

@Tribex punto justo.
Tal vez package.electron puede ser solo una especie de enlace que le dice al tiempo de ejecución "Hey, take a look at package.json, it should contain the info on how to launch it" . Esta fue una idea "loca", así que sí, estoy bien con modificarla.

Estoy de acuerdo con @tribex , necesitamos O BIEN un archivo separado o cambiar el nombre del paquete.json. a otra cosa

@wurysolovoyov no puedes hacer eso. Lo único que puede abrir un archivo es tener una extensión adjunta, en cuyo caso todas las extensiones se abrirán con el mismo software. Entonces, a menos que esté de acuerdo con no poder abrir un .json con otra cosa que no sea electron (lo que simplemente generaría un error, a menos que se abra una aplicación de electrones adecuada), aún puede hacerlo, pero que nosotros, los que queramos poder abrir archivos .json , podamos abrirlos con el programa con el que queramos abrirlos.

De lo contrario, no podrá editar el archivo, sin abrir primero el editor o cambiar lo que se abre .json cada minuto más o menos.

Me refiero a @YurySolovyov no @wurysolovoyov

Tal vez no lo dije claramente: el propósito de package.electron es solo servir como un marcador de que este directorio es una aplicación, para que el tiempo de ejecución pueda referirse a package.json que está en la misma carpeta e inicie una aplicación. Si abre package.json directamente, se abrirá en lo que esté asociado con .json en su sistema operativo.

Algo así como un sistema de atajos.

@YurySolovyov En ese caso, es solo una cuestión de gusto si definimos esa información en package.json o package.electron. Yo personalmente lo mantendría separado simplemente porque me parece más limpio. Sin embargo, tal vez la propiedad de los motores en package.json sería suficiente.

@Tribex también es un requisito para publicar la aplicación en npm: tener package.json válidos

@YurySolovyov Cierto. Si usáramos package.electron, package.json aún estaría presente. .electron solo se usaría para definir información de tiempo de ejecución o, en el caso de su sugerencia, solo sería un marcador.

Básicamente, el package.electron solo estaría allí como un _marcador_ ejecutable, por lo que el paquete.json aún estaría presente con sus propios datos, pero es por eso que se necesitaría un archivo separado: _doble clic abre la aplicación_ . Todavía me gustaría poder cambiar el nombre de package.electron a my-app.electron o my-app.electron .

@sapioit seguro, ese es el objetivo de tener un archivo .electron , puede nombrarlo como quiera, siempre que tenga la extensión .electron .

Todavía no me parece muy claro que el controlador de tiempo de ejecución tenga que buscar en *.electron, luego en package.json para determinar qué versión de electron ejecutar, que luego vuelve a leer package.json.

@Tribex , ¿por qué cree que package.json se leería dos veces?

• Si ponemos la información del tiempo de ejecución en el archivo .electron , el tiempo de ejecución iniciaría la aplicación usando package.json asumiendo que todo es correcto y falla rápidamente si no lo es.
• Si colocamos el tiempo de ejecución en package.json directamente o en la sección electron , eso también requeriría solo 1 lectura. De esta manera, no estoy seguro de qué poner en el archivo .electron (¿ideas?), estaría bien incluso si estuviera vacío.

@tribex El .electron podría apuntar a package.json , por si acaso, por alguna razón, se cambia el nombre de package.json. De esta forma, podría tener un package.json para NPM y un package.json diferente (tal vez electron.json ) para el Electron. ¿Por qué? Tal vez desee que su aplicación tenga el paquete.json para saber qué cosas importar con el administrador de paquetes, pero una vez importado, desea ejecutarlo sin necesidad de mover o cambiar el nombre de los archivos.

_ app.electron _

{
  "package": "package.json",
  "recommended": "1.2",
  "compatible": [
    "1.2.1-1.2.5",
    "1.3,1.3.0.1",
    "1.1"
  ]
}

o

_ myapp.electron _

{
  "package": "electron.json",
  "recommended": "1.2",
  "compatible": [
    "1.2.1-1.2.5",
    "1.3,1.3.0.1",
    "1.1"
  ]
}

O bien, si ponemos todo en package.json , podríamos tener el enlace de .electron solo al .json que queremos usar para abrir la aplicación, entonces:

_ app.electron _

{
  "package": "package.json"
}

o

_ myapp.electron _

{
  "package": "electron.json"
}

Además, tal vez quieras tener dos lanzadores en el mismo directorio, uno para el cliente y otro para el servidor, con el cliente usando los archivos del servidor para lanzar un servidor local con un solo jugador. De esta forma, no necesitará duplicar el 99 % de los archivos (asumiendo que tiene un juego que usa más de 500 MB de archivos) y 5 o 6 archivos diferentes, y tenerlos en dos directorios separados, pero solo tener uno extra. archivo para poder iniciar el servidor por sí mismo. Literalmente, lo mismo que tener múltiples ejecutables en el mismo directorio.

El package.electron separado debe llamarse package.electron.json o algo que tenga la extensión .json por el bien de los editores y el IDE para determinar la sintaxis correctamente.

@StreetStrider Prefiero enseñarles a los IDE que .electron es realmente válido .json .
Y esto también nos lleva al punto que discutimos con @sapioit sobre las asociaciones de .json . No creo que ningún sistema operativo popular admita asociaciones de doble extensión. ( .foo.bar )

Puede agregar la extensión .json cuando la edite. o haga clic con el botón derecho y abra con un editor, pero al igual que Adobe Air, que, de manera predeterminada, abre el archivo con su lanzador, lo que permite al usuario abrir el archivo con un editor, eso no causaría problemas.

@sapioit Punto justo, supongo que estoy de acuerdo con usted entonces acerca de señalar el paquete.json.

Para mí, un tiempo de ejecución y un reproductor son dos cosas separadas. Esto está saliendo más como jugador ahora. Y no parece que tenga un uso generalizado fuera de una comunidad técnicamente inclinada que está acostumbrada a los conceptos de administradores de paquetes.

El problema en cuestión es crear un tiempo de ejecución. Algo así como JRE y .Net. No es un jugador.

@baconface ¿Quizás podrías dar más detalles? No está claro cuál es la distinción que está haciendo aquí.

@baconface sí, pero tanto JRE como .Net también se pueden instalar.
Sin JRE, los archivos .jar son tan inútiles como los paquetes sin tiempo de ejecución electron .

Idealmente, esta herramienta se distribuiría con o como el método principal para instalar electrones, idealmente aliviando el problema de la propagación.

Para esto, solo necesitaría una pequeña herramienta para crear un ejecutable que lanzaría un determinado archivo, a saber, el .electron imputado. Simple como eso.

.lept se ve increíble, ¡gracias!

Personalmente, creo que no hay necesidad de inventar ninguna configuración nueva, pkg.engines me parece bastante sencillo aquí (aunque debería permitir algunas expresiones de semver complicadas, como 1.x || >=2.5.0 || 5.0.0 - 7.2.3 de los documentos de npm , por lo que no es necesario { recommended, compatible, etc } -estructuras como en los ejemplos de @sapioit , creo). (Sin embargo, he agregado un campo lepton , porque scripts.run generalmente es invocado por npm start , y lepton rompe un poco la semántica al agregar su propio $VARIABLES .)

O, si ponemos todo en package.json, podríamos tener el enlace .electron only al .json que queremos usar para abrir la aplicación.

A mi tampoco me parece una gran idea. Si tenemos un paquete con múltiples puntos de entrada, aún podríamos tenerlos todos en un solo paquete.json, como si tuviéramos un mapa scripts ahora. Estoy pensando en algo así:

// package.json
{
  "engines": {
    "node": "4.x",
    "electron": "1.x"
  },
  "lepton": {
    "run": "$ELECTRON .",
    "server": "$NODE ./server.js",
    "server-debug": "$NODE ./server.js --debug"
  }
}

# lepton-run [DIR OR TARBALL] [CONFIGURATION]
$ lepton-run . # the default configuration is `run`
$ lepton-run . server
$ lepton-run . server-debug

Entonces, si realmente quiere esto como archivos ejecutables, en Linux / macOS puede usar scripts de shell simples (3 líneas incluyendo #!shebang), y en Windows... bueno... ¯_(ツ)_/¯

En primer lugar, es posible que desee echar un vistazo a este artículo, que ofrece una mejor alternativa a semver, sin dejar de ser compatible con casi todo lo que existe: Release.Breaking.Feature.Fix o por qué la versión semántica debe reemplazarse con el control de versiones explícito como tan pronto como sea posible

En segundo lugar, la pregunta es cómo diferenciarlos realmente. Quiero decir, si server.js ya acepta el argumento --debug , ¿por qué molestarse con eso y no permitir que las personas tengan sus propias configuraciones de archivos? Tal vez el servidor requiera configuraciones diferentes a las del cliente, como que el cliente trabaje en 2.2-2.4 y el servidor solo en 1.4-1.9.2.1 ...
Haciendo lo que sugieres, solo estaríamos más limitados.

Además, ¿qué pasa con el uso de más variables, no solo --debug ? ¿Cómo voy a ejecutarlo con más variables como esta? ¿Es seguro hacer eso? Después de todo, si quisiera que un archivo hiciera eso, podría haberlo hecho incluso con archivos separados, pero de esta manera se estropea con los posibles resultados de ejecutar el archivo .lept con parámetros.

Si quisiera ejecutar el servidor con el parámetro de depuración, ¿no lanzaría simplemente el .lept con el argumento --debug ? O podría crear otro archivo para iniciar ese archivo con el argumento --debug . ¿No es así de simple?
Espero tener sentido...

En primer lugar, es posible que desee echar un vistazo a este artículo, que ofrece una mejor alternativa a semver

Creo que esta es una gran idea! Sin embargo, no creo que Electron vaya a cambiar a este esquema de versiones. También creo que si bien es excelente para productos de usuario final, en realidad no lo necesitamos para bibliotecas, motores, tiempos de ejecución y demás. Idealmente, el usuario ni siquiera debería saber qué versión de Electron está ejecutando (a menos que así lo desee).

Tal vez el servidor requiera configuraciones diferentes a las del cliente

Esto podría ser un problema, pero no puedo imaginar un proyecto que necesite más de una versión de un tiempo de ejecución.

Si quisiera ejecutar el servidor con el parámetro de depuración, ¿no lanzaría simplemente el .lept con el argumento --debug?

Si, Por qué no:

# lepton-run [DIR OR TARBALL] [CONFIGURATION] ARGS...
$ lepton-run . server --debug --myoption=5
# resolves to:
$ path/to/node ./server.js --debug --myoption=5

Este paquete de configuración dual.json es excelente para los casos en que el servidor a) comparte una gran cantidad de código base con el cliente y b) está diseñado para que lo ejecuten los usuarios finales. En otros casos, tendría sentido separarlo todo en dos repositorios/paquetes, cada uno con su propio paquete.json.

No es por Electron, sino por los proyectos que construyes. Es probable que Electron tenga su propio sistema derivado de Semantic Versioning para satisfacer sus necesidades, y es poco probable que lo cambien, pero para Lepton y otros proyectos que no están tan lejos en _ development hell _, podría ser una buena idea omitir por completo las versiones semánticas.

Si quisiera ejecutar el servidor con el parámetro de depuración, ¿no lanzaría simplemente el .lept con el argumento --debug?

Si, Por qué no:

# lepton-run [DIR OR TARBALL] [CONFIGURATION] ARGS...
$ lepton-run . server --debug --myoption=5
# resolves to:
$ path/to/node ./server.js --debug --myoption=5

No, no me refiero a la configuración, sino a través del lanzador. Así que esto:

# lepton-run [DIR OR TARBALL] [CONFIGURATION] ARGS...
$ lepton-run . server --debug 

Pero lanza .lept con el argumento --myoption=5 sin tocar los archivos (además de abrirlos). Como estoy bastante seguro de que puede "_empujar_" el argumento a través del iniciador, también puede eliminar la necesidad de --debug , ya que lo iniciará con el argumento personalizado si lo desea.

Pero en una cosa creo que podemos estar de acuerdo: los usuarios quieren estar en una versión estable para la que están recibiendo soporte. Es por eso que hice el " Lanzamiento " en su propio número, porque es poco probable que las personas recuerden muchos números, pero generalmente recuerdan el primero.

@sapioit si el campo "Release" es para usuarios finales, ¿para qué sirven los otros? Para el usuario final, esto no debería importar en absoluto, si hay una nueva versión disponible y requiere un tiempo de ejecución actualizado (mediante un aumento en el paquete.json), entonces el tiempo de ejecución también debe actualizarse.

Aquí están los problemas:

1. Los usuarios quieren saber para qué versión se les ofrece soporte .
2. No quieren recordar muchos _números inútiles_, por lo que si eligen recordar la versión, es más probable que recuerden la versión 13 que la versión 1.7 (por ejemplo).
3. Algunas personas no quieren actualizar hasta que suceden ciertas cosas, como que muchos controladores de nVidia no se actualizan porque desde que se agregó la compatibilidad con Thunderbolt, sus tarjetas gráficas se expulsan al azar (dependiendo del usuario/caso , ya sea después de encender la computadora, después de abrir un juego o unos minutos después de jugar). Este es un buen ejemplo de una razón (pero hay muchas otras, como los anuncios de KMPlayer o locked on actualizaciones automáticas ) que impiden que los usuarios usen la última versión de un producto. Esto hace que sea más fácil mirar el registro de cambios, al quitarle complejidad.

Esas son solo algunas de las razones... si pudiera entrar en más detalles, también podría entrar en más detalles y explicarle mejor por qué se tomaron esas decisiones.

@sapioit ¿No son los rangos de semver como >= 12.1 lo suficientemente flexibles para declarar soporte?
Si hay una nueva versión del tiempo de ejecución disponible y cumple con el rango de versiones, todos los próximos lanzamientos de una aplicación deben usar el último tiempo de ejecución posible.

¿Deberían ellos? Pero, ¿qué pasa si deciden no hacerlo debido a limitaciones técnicas (como la publicidad de KMPlayer y los controladores de nVidia)?

@sapioit Entonces solo asegúrese de haber establecido su rango de tiempo de ejecución correctamente

@sapioit @YurySolovyov ¿Esta discusión es relevante aquí? Un administrador de tiempo de ejecución tendría que seguir cualquier sistema de control de versiones que esté usando electron. Creo que una discusión sobre qué sistema de versiones electron _debería_ estar usando pertenece a otro número.

@Tribex algo. Estaba tratando de decir que no debemos complicar demasiado las cosas que ya están básicamente resueltas. Pero estoy de acuerdo en que el administrador de tiempo de ejecución debería hacer lo más simple posible a este respecto.

@yurysolovyov Entonces, ¿por qué no permitir simplemente tantas secciones en el número de versión como el jugador quiera?

@sapioit

No es por Electron, sino por los proyectos que construyes.

Lepton no tiene un esquema de versiones asignado (todavía), y los paquetes (aplicaciones) pueden usar cualquier esquema de versiones que deseen. Necesitamos manejar esto (por ejemplo, si queremos admitir la actualización de aplicaciones a través del propio Lepton).

Idealmente, los tiempos de ejecución deberían usar semver, ya que no son productos, pero nuevamente, ahora se admite cualquier versión de 3 números (aunque los desarrolladores deberían tener cuidado al especificar rangos). Si alguna vez necesitamos admitir más de 3 números (como con su propuesta de control de versiones explícito), tendríamos que ampliar el analizador (para Python, sugiero bifurcar k-bx/python-semver o podhmo/python-semver , el primero se actualizó más recientemente, mientras que el primero sigue la API de node-semver más estrictamente y es lo que estoy usando actualmente).

¿Puedo decir que tener un administrador de paquetes de tiempo de ejecución escrito en python para un proyecto de nodejs es simplemente una mala idea?
Simplemente no lo hagamos. Como se llame, lepton, o lo que sea. Escribámoslo en node, o usemos algo más. Y no enviemos este problema con correos electrónicos innecesarios sobre cómo crees que sabes más que el esquema de control de versiones semántico bien pensado.

@championswimmer Sería interesante construir el administrador de tiempo de ejecución con una versión de electron empaquetada con él y una interfaz de usuario para mostrar cuándo se descargan otras versiones.

@championswimmer iamale/lepton es una especie de implementación de referencia desechable: solo lo puse para probar varias ideas que flotan en este hilo, nada más.

@iamale , ¿tal vez debería indicarlo en el archivo Léame para evitar confusiones?

@YurySolovyov Listo!

En cuanto a la implementación real, tenemos dos opciones: o usamos node.js o un lenguaje compilado como C/++ o Go; y para el nodo, tendríamos que empaquetar node.js con él (¿o tal vez simplemente ejecutarlo en una de las instancias de electrones descargadas? Sin embargo, debemos asegurarnos de que se ejecute en _cualquier_ versión de electrones).

@iamale No realmente, solo tenemos que ejecutar una versión instalada predeterminada. Después de eso, las actualizaciones pueden cambiarlo a una versión más nueva en el lugar.

Prefiero elegir usar una determinada versión, porque si es necesario, todo se puede actualizar...

Lepton podría no ser un gran nombre ahora que es un formato de imagen .

Entonces... ¿cómo lo llamamos ahora? Hadron ?

¿Cuarc? Si alguien quiere tomar el nombre de "Muon" puedo cambiar el nombre de uno de mis proyectos.

¿No es nombrar en realidad la parte menos importante aquí?
¿Acordamos la semántica de instalación/actualización/tiempo de ejecución?

¿Por qué no solo electron ...

Op 15 jul. 2016 om 13:22 heeft Joshua Bemenderfer [email protected] het volgende geschreven:

¿Cuarc? Si alguien quiere tomar el nombre de "Muon" puedo cambiar el nombre de uno de mis proyectos.

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

@yurisolovyov Creo que estuvimos de acuerdo... más o menos.
@job-v Eso es lo que he estado sugiriendo todo el tiempo. Simplemente escojamos uno y sigamos con él.

@zcbenz ¿estás observando este hilo?
Si es así, sería bueno tener una visión de cómo debería funcionar esto para obtener algunas instrucciones aquí.

Hola
¿Alguna actualización sobre este tiempo de ejecución de electrones ?
@zcbenz , ¿qué piensas sobre toda la discusión sobre:

• selección de la versión de electrones
• instalando la versión apropiada
• prepararlo para trabajar en win, linux, mac
• ¿Qué herramienta usa para construir con él (python, node, go, c ++)?
  @YurySolovyov @sapioit gracias por tus increíbles ideas
  @iamale es su trabajo de solución para destros basados ​​en Debian 'ubuntu...'

@alnour-altegani
Sí, funcionaría para cualquier distribución basada en dpkg porque no dependemos de paquetes externos. Los paquetes RPM se pueden generar de manera similar, ¿por qué no?

Estoy pensando en iniciar un repositorio central para todas las cosas de Electron, por ejemplo, podrías ejecutar:

sudo sh -c "echo 'deb https://epkg.example.org/ /' > /etc/apt/sources.list.d/epkg.list"
sudo apt-get update
sudo apt-get install min-browser  # or whatever

@iamale Creo que hacer electron como paquete deb y usarlo como dependencias en la aplicación para instalarlo manualmente o desde el repositorio central para muchos paquetes deb de versión electrónica.
y luego use este paquete después de la instalación para ejecutar la aplicación de usuario

Si alguien comienza a trabajar en algo para esto, tal vez enlace aquí...

@sapioit Empecé a trabajar en una solución Linux (APT/RPM). Un servicio simple en el que carga .asar y se convierte en paquetes y se agrega a los repositorios. También debería ser extensible a Windows y macOS, pero no hay promesas al respecto por ahora.

@iamale Genial! Avísame cuando lo hagas funcionar en Windows.

¿Qué hay de hacer un tiempo de ejecución de Flatpak para Linux? De esta manera, el tiempo de ejecución se puede compartir entre varias aplicaciones y también obtienes sandboxing.

Con Flatpak eliminando su dependencia de systemd , probablemente se volverá universal en Linux para el empaquetado ascendente.

el tiempo de ejecución se puede compartir entre varias aplicaciones

Pensé que con Flatpak no sería posible?..

@iamale Flatpak está diseñado para compartir tiempos de ejecución: los desarrolladores de aplicaciones eligen un tiempo de ejecución, instalan el SDK para ese tiempo de ejecución y luego crean una aplicación con flatpak-builder o similar. Luego, cuando el usuario instala la aplicación, Flatpak instala el tiempo de ejecución asociado.

@moosingin3space ¡ Gracias por la explicación! Definitivamente vale la pena considerarlo entonces.

La otra cosa que me gusta de Flatpak es que se diseñó en torno al caso de uso en el que un usuario agrega un repositorio ejecutado por el desarrollador de tiempo de ejecución y el desarrollador de la aplicación (transparentemente) y esto hace que las actualizaciones sean automáticas.

Las únicas cosas que puedo ver como problemas están relacionadas con la seguridad: es necesario modificar las bibliotecas del sistema para usar la interfaz de "portales" en Flatpak para permitir una salida segura de la zona de pruebas.

Parece que hay trabajo en Flatpak aquí: https://github.com/endlessm/electron-installer-flatpak

Como nota al margen, Flatpak se basa en el proyecto OSTree , que hace el direccionamiento de contenido para los árboles del sistema de archivos. Esto significa que los archivos con sumas de verificación idénticas se desduplican automáticamente en el disco y que las actualizaciones se realizan mediante deltas estáticos. Esto significa que no solo Electron podría proporcionar un tiempo de ejecución compartido que se puede actualizar y compartir de forma independiente entre aplicaciones, sino que también las aplicaciones creadas en archivos idénticos los compartirían automáticamente en el disco, y que una vez que se instala una aplicación y/o un tiempo de ejecución, las actualizaciones no requeriría una descarga completa.

Perdóneme si esto es un poco ingenuo, me pregunto si se ha considerado la posibilidad de construir un entorno de escritorio como una progresión lógica natural del entorno de tiempo de ejecución. La idea es que haya una aplicación de lanzamiento que cargue electrones al inicio (en lugar de, digamos, atom) con la capacidad de lanzar otras aplicaciones de electrones (dada la gran biblioteca en crecimiento) generando nuevas instancias del renderizador o tal vez incluso reutilizándolo y tener las aplicaciones se abren en una nueva pestaña.

Chrome, como en el sistema operativo, según tengo entendido, parece ser exactamente esto (pero se limita a las aplicaciones web). Tener aplicaciones de escritorio con acceso fs completo a través de nodejs (a diferencia de las limitaciones de chromeAPI) con electron como entorno de tiempo de ejecución sobre Linux (o incluso reemplazar o al menos aumentar al principio explorer.exe en Windows) sería muy emocionante en mi humilde opinión. Creo que esta es una solución más limpia que ChromeOS que está cargando lo que es efectivamente un tiempo de ejecución y luego un motor de navegador y luego aloja una aplicación; aquí uno cargará aplicaciones directamente en el tiempo de ejecución y el navegador en sí será solo otra aplicación (y hay tantas muchos proyectos innovadores de navegador de electrones en la naturaleza).

Nuevamente, me pregunto si esto se ha considerado o si ya hay algún proyecto que lo esté haciendo. Si no, ¿quizás un hada pueda poner una palabra en los oídos de la gerencia de Github para tomar la iniciativa?

PD: Una cosa que no estoy sugiriendo aquí es portar OS.js (que es un pequeño y lindo proyecto en sí mismo) a electron, sino crear un entorno para aplicaciones de electrones (aunque no me opondría a la reutilización de código de OS.js).
PPS: crearé un problema separado si se considera lo suficientemente valioso o si es una distracción para el problema de un entorno de tiempo de ejecución.

Creo que un entorno de tiempo de ejecución integrado mejoraría mucho las aplicaciones de Electron. Creo que empaquetarlos debería ser simplemente comprimir los archivos y cambiar el nombre de la extensión a asar , pero ese archivo debería tener dos carpetas, una llamada asar , con el contenido de la carpeta de tiempo de ejecución predeterminada, y otra llamado enviroment con archivos que deberían sobrescribir la configuración predeterminada.

Por ejemplo, ejecutar una nueva aplicación copiaría la versión requerida de Electron en una carpeta temporal y movería el tiempo de ejecución (el contenido de la carpeta asar ) a la ubicación de archivos predeterminada, mientras que la carpeta opcional enviroment (con 3 subcarpetas, windows , linux , macosx ) debe contener archivos que se pegarían sobre la carpeta predeterminada, sobrescribiendo su contenido.

De esta manera, solo necesitamos una aplicación o algo para evaluar la extensión .asar de una aplicación y hacer que esa aplicación acceda a la carpeta con las versiones descargadas de Electron (archivadas), cópielas (extráigalas) en una carpeta temporal , y use el contenido de .asar para modificar lo que se necesita, luego ejecute la instancia de Electron desde esa carpeta temporal y espere a que muera para forzar la eliminación de la carpeta temporal. Para empezar, incluso lograr que la configuración predeterminada funcione con un archivo con una extensión personalizada en todos los sistemas operativos compatibles sería mucho más de lo que ya tenemos. Después de eso, podemos preocuparnos por tener una tercera carpeta, config , donde guardar los ajustes de configuración actuales, y tal vez una carpeta _config dentro, para los ajustes de configuración predeterminados (si los necesitamos). ).

Dado que las aplicaciones empaquetadas de Chrome se eliminarán pronto, la gente buscará alternativas. Un tiempo de ejecución sería excelente para esos proyectos menores que no siempre van a tener compilaciones/versiones disponibles. Dado que las aplicaciones están hechas con tecnología web al igual que las aplicaciones de Chrome, sería valioso para un usuario simplemente ejecutar la aplicación desde la fuente. No puedo justificar la transferencia de innumerables proyectos menores a Electron si la única forma en que un usuario puede ejecutarlos es descargar una gran versión binaria para cada script o aplicación individual, y los usuarios no pueden aprovechar la ejecución de la última confirmación sin compilarla o descargar la versión de Electron. IDE ellos mismos.

Hola a todos, incluso si no estoy en el mundo centrado en JS, recientemente tuve una idea bastante similar a _Electron_ (que conocía, pero no uso para el desarrollo) pero con una audiencia más amplia; para decirlo de una manera muy simple: _simplemente limite las tecnologías web a la GUI y proporcione las API._

Así que continúe con una biblioteca / tiempo de ejecución compartido con versiones semánticas (construido sobre _Blink_, _Skia_, etc; tal vez en - "moderno" - _C++_) y deje que los desarrolladores elijan el lenguaje usando enlaces...
por ejemplo, quiere _JS_, use _Node.JS_; quieres _C++_, no hay problema; quieres _Python_, con el estándar _CPython_ debería ser posible; Algo más ? tal vez _SWIG_ pueda ayudar. En (casi) cualquier caso, ganamos.

Una vez que tenemos la biblioteca/tiempo de ejecución compartido (dependiente del sistema operativo), resuelve el problema principal y puede elaborar cualquier forma que crea que es mejor para entregar el resto (aparte de revolucionar/modernizar el enfoque de programación de GUI para el resto de nosotros; un ¡un gran paso adelante!).

Entonces, el punto de partida debería ser la "división" (incluso debería tener un nombre relacionado con la física, dado que parece que realmente te importa) del proyecto _Electron_... :)

Ni siquiera podemos hacer un complemento para Electron, pero creo que no tendrá mucho éxito, a menos que haya mucha publicidad.

@dezzeus Hubo un esfuerzo en estas líneas antes del cual fracasó. Eche un vistazo al tiempo de ejecución de empuje destinado a alojar el navegador de brechas.

Leí este largo y fascinante hilo dos veces, ya que me encantaría ver más impulso en esta dirección. Aquí está la última declaración de @zcbenz , creo que todavía es relevante:

No hay ningún obstáculo técnico para implementar esto, todo puede ser una aplicación de Electron en sí misma. Pero el problema es que tampoco es fácil de implementar, teniendo en cuenta todos los detalles, creo que _requiere un pequeño equipo trabajando a tiempo completo en ello_, no estoy seguro de si alguna vez sucederá.

(Énfasis agregado): cómo interpreto esto es que, si la solución alguna vez se va a construir, dependerá del esfuerzo de la comunidad y/o las necesidades comerciales de GitHub y otras organizaciones con intereses en ella.

Una descripción general concisa de @yan-foto parece un plan de enfoque sensato, con objetivos/requisitos claros. Hay una implementación/prototipo de referencia llamado lepton por @iamale , que propone un "administrador de versión de tiempo de ejecución universal" dirigido a Electron. Un comentario de @jorangreef fue intrigante, ya que describe "una aplicación en producción con un mecanismo de actualización automática de semver", con actualización diferencial, deduplicación (no estoy seguro si esos dos son iguales) y compresión. Muchas de las características que describió parecían perfectas para adaptar/adoptar.

Estos son pasos definitivos de exploración y progreso, y me da la esperanza de que de este proceso surgirán soluciones generales dignas de producción.

Es bueno ver que todavía hay gente con fe en la humanidad.

Lo único que impide que esto se convierta en un producto es la falta de oportunidades comerciales inmediatas abiertas por la fabricación de este producto (concepto).

@eliot-akira sí, eso es lo que es. El código que he escrito realiza una deduplicación basada en el contenido por archivo (fragmentos de tamaño variable) dentro de un archivo para minimizar las descargas cuando solo cambian unos pocos bytes dentro de un archivo. También actualiza solo aquellos archivos que cambian entre versiones y las actualizaciones de la aplicación en su conjunto son atómicas frente a cualquier error. Se lanzará la nueva versión o se mantendrá la versión anterior.

Me gustaría abrir el código y hay algunas cosas que aún necesitaría codificar para la idea general. Sería genial si varias aplicaciones de Electron pudieran compartir un único proceso de supervisión de actualización automática (con un caché local inmutable compartido para la deduplicación en varias aplicaciones de Electron independientes).

El objetivo de todo este enfoque sería minimizar el ancho de banda de descarga general requerido para instalar y actualizar las aplicaciones de Electron, manteniendo las aplicaciones de Electron completamente aisladas entre sí (varias aplicaciones tendrían sus propios archivos binarios de Electron). Un no-objetivo sería minimizar la huella del disco.

La primera instalación de la aplicación Electron debería descargarse por completo, pero las instalaciones posteriores de la aplicación Electron se beneficiarían del caché inmutable compartido local.

Dado que se trata de una actualización automática, tengo que mencionar el problema de las versiones y el hecho de que varios sistemas de versiones parecen estar usando diferentes números de dígitos para las versiones. Yo, por mi parte, estoy usando versiones explícitas .

Tenemos dos tipos de cosas que deben actualizarse aquí:

• El propio Electron, que utiliza versiones de electrones y
• Aplicaciones, para las cuales realmente no necesitamos preocuparnos por SemVer ni nada, ya que generalmente no tienen una API (a menos que utilicen algún tipo de sistema adicional, tal vez).

Aunque si necesitamos admitir varios sistemas de control de versiones, tal vez podríamos tener alguna configuración en package.json , como "breakingVersionComponents": 1 para semver y 2 para control de versiones explícito o control de versiones de electrones.

(Otra opción sería agregar otro separador en la versión, como 1.3:3.7 , que separaría las partes rotas y no rotas. Semver se convierte entonces en x:y.z y Electron Versioning x.y:z . Esto sería Sin embargo, creo que romper todas las herramientas que existen.)

@jorangreef Si cada aplicación todavía tiene su propio binario de Electron, esto no solucionaría el problema del uso excesivo de RAM cuando se tienen múltiples aplicaciones de Electron abiertas.

Noté un comentario anterior de @joshuawarner32 , que había pasado por alto. Menciona un ejemplo que ya funciona, que aún no es una solución de propósito general, pero el resumen es:

- Deploy .asar.gz files for several different apps on a server
- Distribute a single build of atom-shell to users, which doesn't bundle any code for specific apps
- On app startup, download the appropriate .asar.gz file (if it's not there, or there's a more recent one on the server). Extract it and run the contained app.
- Our atom-shell build accepts a --app argument to specify which app to download/run

Junto con el ejemplo de @jorangreef (gracias por la explicación adicional - editar: oh, no me di cuenta de que cada aplicación tiene su propio binario Electron, que es un modelo diferente de lo que pensaba), veo que la gente ya está construyendo su propias soluciones específicas al problema de un tiempo de ejecución compartido, que también proporciona características de un iniciador/administrador de aplicaciones de algún tipo. Sería genial ver cierta convergencia, para desglosar algunas de estas características mencionadas en módulos de propósito general.

Me pregunto si hay módulos existentes no específicos de Electron que podrían aprovecharse, como el mecanismo de descarga: servidor de tiempo de ejecución, control de versiones, actualizaciones diferenciales. Parece un poco desalentador construirlo todo desde cero, si otros ya han "resuelto" algunas de estas áreas. @iamale , gracias por su trabajo en Lepton , en mi opinión, esta es una implementación concreta en la dirección de una solución.

Otra idea: simplemente publique aplicaciones en npm y cree un contenedor especial de npm que pueda instalarlas y ejecutarlas. Sería realmente fácil de implementar entonces y probablemente también fácil de usar (dependiendo de la calidad del envoltorio). ¿Qué piensan chicos?

Para proyectos de oss, podríamos usar npm como alojamiento, para los de código cerrado, necesitamos poder apuntar el administrador de paquetes al archivo .asar para descargar, y tal vez algunos metadatos más. La pregunta es, ¿cómo se verá (y se llamará) este amable gerente?

Además, me pregunto si realmente necesitamos un comando separado para instalar aplicaciones, tal vez solo
electron install atom sería suficiente?

Acabo de ver esto en Node Weekly:

Electrino es una alternativa experimental de peso pluma al popular y poderoso Electron. Implementa una porción minúscula de las API disponibles en Electron, pero el tamaño de la aplicación de salida es mucho más pequeño.

https://medium.com/@pauli/pon-tu-electron-app-en-una-dieta-con-electrino-c7ffdf1d6297

https://github.com/pojala/electrino

@YurySolovyov Los proyectos de código cerrado no deberían tener problemas para ser publicados en npm también; ya hay algunos de Node.js, es decir, enclose . (Técnicamente, no está en npm, solo un cargador, pero de todos modos, no puedo ver cómo ayudaría la carga lateral de .asar, ya que aún se pueden desempaquetar).

Solo estaba tratando de pensar cómo podemos reutilizar la mayor cantidad posible del ecosistema existente.

No estoy seguro de querer...

@jorangreef Si cada aplicación todavía tiene su propio binario de Electron, esto no solucionaría el problema del uso excesivo de RAM cuando se tienen múltiples aplicaciones de Electron abiertas.

@ Jop-V No, no lo haría. No quiero confundir las cosas y terminar con un monstruo. La idea es tener un excelente instalador/actualizador automático que resuelva la mayoría de los problemas en el comentario que abrió este número: https://github.com/electron/electron/issues/673#issue -44580957

El problema no es tanto tener varios binarios en el disco, sino el impacto de la red en que un usuario tenga que descargar y actualizar automáticamente varias copias del mismo binario.

Sin embargo, definitivamente vale la pena resolver el uso de la memoria. Creo que hay una variedad de formas de hacerlo, pero no necesariamente deben incluirse con un instalador/actualizador automático de deduplicación.

Si la huella del disco también es un problema, se puede abordar a través de enlaces fijos en los sistemas que lo admiten, aunque eso comenzaría a infringir la idea de aislamiento entre aplicaciones (por ejemplo, si una aplicación decide escribir en un enlace fijo compartido con otra cosa).

Alternativamente, al menos en macOS a mediano plazo, APFS copiará archivos por referencia, con deduplicación transparente bajo el capó, minimizando el espacio en disco. Esto sería mejor que los enlaces duros, ya que mantendría intacto el aislamiento (copia en escritura).

@jorangreef ¿Cuál es el punto de usar binarios de Electron separados para aplicaciones? ¿De qué tipo de aislamiento estás hablando? Lo siento si es una pregunta tonta, pero no lo entiendo.

@iamale Algunas aplicaciones pueden apuntar a diferentes versiones oficiales de Electron, o pueden distribuir un Electron preconstruido compilado a partir de fuentes modificadas. Este enfoque funcionaría con todos ellos. Incluso con grandes diferencias en los binarios (a diferencia de JS y los cambios de activos), la deduplicación eliminaría el 70 % o más de los requisitos de descarga, por lo que las aplicaciones que apuntan a diferentes binarios aún se beneficiarían.

Con este enfoque, incluso es posible enviar cualquier tipo de paquete (cualquier conjunto de archivos y directorios definidos por un manifiesto JSON), no necesariamente solo aplicaciones de Electron. También puede ser una aplicación de Python. Es independiente de cualquier elección que el desarrollador quiera hacer con respecto a cómo estructuran o empaquetan su aplicación (archivos vs asar, etc.).

La idea principal es que el ecosistema se beneficie de deltas de instalación/actualización muy pequeños, ya que cada vez más aplicaciones usan el mismo instalador/actualizador automático. En estos días, cada aplicación ejecuta su propio actualizador automático de supervisión y no es necesario.

@jorangreen ¡Gracias! Supongo que es muy parecido a los repositorios APT/RPM clásicos, simplemente más "inteligentes" (no es necesario declarar sus dependencias ni nada).

La pregunta es, ¿cómo se verá (y se llamará) este amable gerente?

¿Qué pasa con Minifitron (electrón minificado)?

Creo que el archivo de almacenamiento (es decir .asar ) debe contener el contenido de la carpeta donde está el binario de electrones, para que podamos agregar o reemplazar los archivos que se desvían del estándar. Tendremos cada versión en una carpeta o archivo y la copiaremos en una nueva carpeta temporal durante el tiempo que se ejecute.

Y debería haber una opción para tener las aplicaciones instaladas o minificadas, la instalación las dejaría como una nueva instancia de electron, mientras que minified usaría md5 para eliminar los archivos que no han sido modificados por el desarchivo de .asar (o lo que estaríamos usando) y archivarlo y reemplazar el archivo original, como un estado actualizado de la aplicación que usamos.

Solo para agregar otra idea: ¿qué pasaría si cada aplicación de Electron contuviera sus propias copias de los tiempos de ejecución, pero al momento del lanzamiento, pudieran verificar si hay una instancia de Electron que ya se está ejecutando (y su versión), si es compatible (dentro del rango de semver , etc.), la aplicación podría comunicarse con él y usar esa misma instancia; si no es compatible, la aplicación puede iniciar su propia instancia de Electron. Eso parecería abordar el problema de reducir la huella de memoria.

(Por otra parte, para cuando se inicie la aplicación, supongo que ya habrá varias instancias del tiempo de ejecución de todos modos... por lo que podría no ser lógico...)

@eliot-akira Tuvo una idea muy similar mientras leía este hilo.

(Por otra parte, para cuando se inicie la aplicación, supongo que ya habrá varias instancias del tiempo de ejecución de todos modos... por lo que podría no ser lógico...)

Bueno, podría cargar solo lo suficiente para verificar esto, y después de que vea que no hay un "compañero de electrones" disponible para compartir el tiempo de ejecución, cargue el resto.

Sin embargo, esto crearía muchos problemas de seguridad. Una aplicación malvada podría ofrecer una versión modificada del tiempo de ejecución a otros y acceder a sus datos. Puede ser que pueda usar un segmento de memoria compartida, hacerlo de solo lectura, y las aplicaciones de "usuario" (que usan el tiempo de ejecución de una aplicación lanzada anteriormente) podrían hacer una suma de verificación del tiempo de ejecución, pero desarrollarlas para todos los sistemas operativos objetivo podría ser una pesadilla ( Ni siquiera sé si esto existe en Windows; supongo que debe).

Aunque solo sea por curiosidad, ¿esto no tiene sentido? ¿Sería tanto, o puede ser mucho más trabajo que un tiempo de ejecución compartido por separado? ¿Crea otros problemas adicionales?

AGREGADO MÁS TARDE: Esto podría ser una posibilidad remota, pero existen tecnologías para deduplicar páginas idénticas en la RAM; se utilizan principalmente en entornos de virtualización e hipervisores. Esto es lo primero en lo que pensé y corrí para verificar si los sistemas operativos de hoy en día usan esto, y luego podría haber una manera de configurar el electrón de manera que se pueda aprovechar esta característica, pero aparentemente no.

@jorangreef Si un desarrollador modificó el binario Electron, ¿no debería simplemente crear una solicitud de extracción?

@ Jop-V Pueden, pero también pueden mantener su propio tenedor. Es posible que incluso no publiquen fuentes si no lo desean: la licencia del MIT no les impone ninguna obligación.

@jkurei Para explorar más la idea, imagino un par de formas en que pueden funcionar:

1) Un envoltorio nativo delgado alrededor de Electron o la aplicación en sí, ese sería el "lanzador". Comprueba si hay una instancia de Electron que ya se esté ejecutando y su versión: si es compatible, transfiere el resto del proceso de lanzamiento a esa instancia y sale; si no, continúa lanzando su propia instancia de Electron.

2) Una biblioteca de JavaScript que las propias aplicaciones podrían importar al proceso principal, como iniciador. Podría implementar un protocolo similar al anterior: transmitir la existencia de una instancia de Electron y una forma para que otras aplicaciones (usando la misma biblioteca) la encuentren y se comuniquen con ella, ¿quizás a través del puerto de red?

@eliot-akira Creo, por cierto, que ya hay algún tipo de "protocolo" primitivo del que estás hablando; es esa cosa detrás app.makeSingleInstance que de alguna manera detecta los procesos de Electron que ya se están ejecutando y si son la misma aplicación o no (probablemente al obtener la ruta ejecutable completa).

@iamale Ya veo, el método usa la clase ProcessSingleton nativa de Chromium para registrar el directorio de la aplicación actual (¿como un identificador único?). Sí, me estaba imaginando algo como esto, para ser inicializado antes app.on('ready') . Entonces, en lugar de solo verificar la instancia existente de esa aplicación en particular, podría verificar cualquier instancia de Electron, luego "entregar el proceso de lanzamiento" si es compatible.

Desde otro punto de vista, encontré un módulo llamado node-ipc que puede comunicarse entre procesos separados de Node.js. Tal vez eso podría usarse para administrar el proceso de lanzamiento únicamente en la capa JS.

Este es un ejemplo básico de cómo compartir una sola instancia de Electron entre varias aplicaciones, usando node-ipc para la comunicación entre procesos: https://github.com/eliot-akira/singletron-example.

El concentrador IPC es su propio módulo , una envoltura delgada alrededor node-ipc . Su inicialización está en el proceso principal, main.js en la parte inferior .

Cuando se inicia, la aplicación primero intentará conectarse con una instancia de Electron existente. Si no hay ninguno, iniciará un "servidor" que escucha las solicitudes entre procesos. Cualquier instancia posterior de la aplicación se conectará con la primera instancia, recibirá su "configuración" (versiones de Chrome, Node, Electron) y podrá intercambiar mensajes, por ejemplo, para solicitar una nueva ventana para sí misma.

Para empezar, es una implementación ingenua, pero lo que me gusta del enfoque es que depende de la aplicación manejar cómo el servidor/clientes deben negociar: verificar la compatibilidad, abrir nuevas ventanas, pasar otra configuración, etc.

@eliot-akira Creo que especificar una ID de servidor predeterminada es una idea _muy-muy-mala_ en este punto: si alguien comienza a usar esto para sus propios fines, probablemente modificará su código de ejemplo para sus propias necesidades y romperá el protocolo ( rompiendo así otras aplicaciones que dependen de esto).

Aparte de eso, se ve bien y limpio, ¡gracias!

Re: problemas de seguridad: las aplicaciones de Electron ya se están ejecutando con privilegios de usuario y, si las colocamos en un árbol de procesos, tendrán (o podrán obtener) acceso a otras instancias de Electron. Sin embargo, creo que si vamos a mitigar eso, que todos puedan proporcionar una instancia de Electron parcheada ciertamente no ayudará.

@iamale Gracias por los comentarios. Expuse la opción de configurar la ID del servidor, en caso de que algunas aplicaciones quisieran implementar su propio protocolo, en lugar de uno común para todas las aplicaciones de Electron. De hecho, todavía no existe un protocolo común de este tipo, por lo que, en este momento, no es práctico para ese propósito, que las aplicaciones desconocidas se conecten y transfieran el proceso de inicio. Estaba destinado a ser una prueba de concepto, por lo que actualizaré el documento para mencionarlo. Seguiré explorando cómo hacerlo más práctico.

Creo que sería útil para los recién llegados tener algún tipo de resumen de nuevo, similar al que alguien hizo hace medio año.

Además, ¿qué hace el usuario final?

Si yo fuera el usuario final (y en parte soy ofc), querría un solo paquete .exe/.app/.deb que funcione como el instalador portableapps.net. Ese archivo exe debe ser pequeño y descargar la última versión del software automáticamente junto con el tiempo de ejecución si no se instaló. En un proceso de configuración simple, debería poder establecer una "ubicación de tiempo de ejecución" (usando la casilla de verificación de opciones avanzadas) manualmente junto con las casillas de verificación para crear enlaces del sistema (Escritorio, menú de inicio, etc.).

Cuando descargue el siguiente software, el tiempo de ejecución anterior (sea cual sea su aspecto, idc) debería reutilizarse si es posible.

Como desarrollador, me gustaría poder crear un paquete descargable de este tipo con (en el mejor de los casos) un clic. Este clic debe cargar mi código en algún repositorio (similar a la tienda play/web/app) y crear un paquete .exe/.app/.deb para mí que puedo compartir con el mundo.

Todavía no estoy tan involucrado con Electron, ya que solo estoy creando un pequeño instalador de mods usando Electron y Electron-Edge para C#.

Puedo ser ingenuo, pero afaik, la única razón "real" por la que las cosas no son compatibles con las versiones +-0.1 es que los archivos .node deben reconstruirse para cada versión de Electron. ¿No se podrían crear estos archivos .node durante la instalación usando algún tipo de solución en la nube?

Además, ¿realmente sería tan importante crear un gran Electron LTS cada medio año más o menos? Dudo que los desarrolladores estén usando realmente todas las características de última generación de cada nuevo lanzamiento de Electron, por lo que si los obligamos a quedarse con una versión por más tiempo, eso realmente facilitaría mucho las cosas.

Imo, el único problema es no tener una versión LTS de Electron lista para que todos puedan confiar.

Con esa versión, la actualización automática de compilaciones, la deduplicación, la administración de versiones y todas esas otras cosas deberían ser pan comido.

La solución del instalador que propuse también tiene el beneficio adicional de que el usuario realmente no ve la carpeta del software, por lo que no tenemos que empaquetarlo como .lo que sea y decirle que lo mueva a un lugar seguro. Además, se pueden agregar múltiples "subejecutables" durante la instalación (por ejemplo, para juegos multijugador, múltiples "perfiles", etc.). Estos ejecutables deberían llamarse somelaunchername.electron, pero en formato Json con información sobre cómo iniciar el software (como qué index.html cargar y cosas por el estilo). node_modules debe compartirse entre ejecutables (a menos que el desarrollador NECESITE usar diferentes versiones de un módulo para cada ejecutable). Esto podría lograrse al tener tres carpetas node_modules. Uno para cada ejecutable y otro para ambos. En el paquete.json solo habría información general. Cada archivo .electron debería (imo) poder sobrescribir los valores en el paquete.json.

Estos archivos .electron podrían luego agregarse al menú de inicio y otras ubicaciones utilizando "runtime --appname" o un protocolo personalizado como Steam. No estoy seguro de cuál es mejor, pero el de vapor me ha cabreado varias veces en el pasado.

Ahora, si el desarrollador realmente quiere enviar un tiempo de ejecución modificado, aún puede empaquetarlo de la forma en que se hace actualmente.

Para concluir:
En mi opinión, el siguiente paso es crear una versión estable de lts y lograr que los desarrolladores participen brindándoles una solución de empaquetado fácil. El proceso de instalación podría mejorarse más adelante, actualmente es suficiente descargar un tiempo de ejecución y un lanzador para estos archivos .electron.

¿Qué piensan ustedes?

@CiriousJoker electron-builder puede crear una aplicación portátil y un instalador web. Por lo que veo, en Windows DLL compartido es una solución. El DLL compartido también admite el conteo de referencias, para eliminar automáticamente el tiempo de ejecución de electrones no utilizados. Actualmente, el tiempo de ejecución de electrones en Windows en el único gran exe (excepto node.dll). Si se puede dividir en dll, la solución en el lado del generador de electrones es bastante fácil de implementar. También ahorrará memoria, no solo espacio en disco.

@zcbenz @paulcbetts ¿Ha considerado usar un dll compartido? ¿Es posible reducir el tamaño del exe y mover todo el código de electrones a dll (por lo tanto, mantenga solo el código mínimo en el exe)? Es genial que, dado que electron 1.7.5, el tiempo de ejecución compartido de C se eliminó de node.dll y exe. Ahora, 30 MB de código ya están en los archivos DLL (pero el exe sigue siendo grande: 80 MB), por lo que puedo comenzar a experimentar con él.

@develar imo, el verdadero problema no es cómo podemos compartir dlls, sino cómo podemos obtener una versión lts de electron

¿Chromium incluso realiza correcciones de seguridad para versiones anteriores? Tengo la fuerte sensación de que su política es "actualizar a la última versión para estar seguro". Sin actualizaciones de seguridad de Chromium, un LTS de Electron parece estar muy lejos.

@sedwards2009 Pero, ¿existen realmente tantas amenazas? Claro, podría ser ingenuo aquí, pero no estamos protegiendo a los usuarios del Internet abierto, sino de (principalmente) aplicaciones locales. Ejecutar cualquier archivo .exe es 10000 veces más peligroso y escribir virus .exe también es 10000 veces más fácil cuando incluso el instalador de mi aplicación electrónica legítima fue llamado virus por AVG.

Entonces, para mí, "renovar" esa seguridad cada 6 meses más o menos es suficiente. Además, es mucho más inseguro permitir que cada desarrollador use su propia versión empaquetada de Chrome, podrían hacer mucho más mal con eso de todos modos que no podemos evitar (con un tiempo de ejecución compartido o de otra manera)

Sí, la seguridad termina donde la aplicación obtiene acceso directo a fs y redes.
O confías en el proveedor de la aplicación o te mantienes alejado. <- eso es para aplicaciones de código cerrado.
Para los OSS, es mejor, la mayoría de ellos al menos no tienen malas intenciones, pero pueden contener errores.

Bien, entonces, ¿qué tan fácil es obtener una versión lts? ¿No podríamos elegir la versión actual y declararla una versión lts?

El problema más grande probablemente surgirá más adelante, cuando estemos tratando de convencer a los desarrolladores para que construyan sus aplicaciones para esta versión específica, pero ese es el último paso de todos modos. Para construir un tiempo de ejecución compartido, solo necesitamos elegir un tiempo de ejecución primero

Diría que esta debería ser una decisión del desarrollador: averiguar en qué versiones de tiempo de ejecución debería funcionar la aplicación.
Algo así como npm campo de motores .
El trabajo de Runtime aquí es buscar el dll necesario o lo que sea y permitir que la aplicación se ejecute.

Pero si les permitimos elegir uno de las docenas de casi el mismo tiempo de ejecución que no son compatibles, perderíamos completamente el punto, ¿no? Intentamos evitar tener múltiples tiempos de ejecución, no solo desduplicarlos. Como alguien mencionó en alguna parte al principio, la deduplicación de los tiempos de ejecución no tiene mucho sentido cuando hay una posibilidad entre 20 de que el mismo tiempo de ejecución se vuelva a utilizar en el mismo sistema.

¿O quiere decir que tenemos la mayor parte del tiempo de ejecución compartido y simplemente cambiamos las diferentes partes según sea necesario? Eso tendría sentido, pero imagino que es difícil de implementar.

No veo cómo se puede compartir el tiempo de ejecución, los consumidores de tamaño principal son Chromium y Node, que están estrechamente integrados y dudo que puedan funcionar con más de 1 versión de cada uno.

Creo que el nodo tenía algo así:

• algunos desarrolladores querían la última v8 y estaban de acuerdo en tolerar la rotura
• las grandes empresas querían estabilidad y apoyo a largo plazo.

No estoy seguro de que el equipo de electrones tenga suficientes recursos para apoyar a ambos, pero puedo estar equivocado.
De todos modos, esto no entra en conflicto con los rangos de versiones, solo hay que indicar qué versiones son "LTS"

Bueno, si todas las aplicaciones de electron usan el mismo tiempo de ejecución y solo se envían con el paquete .asar creado específicamente para ese tiempo de ejecución, las cosas funcionarían, ¿no es así?

Sí, pero quieres Chrome y Node más nuevos de vez en cuando, ¿verdad?

Sí, pero podría vivir teniendo el mismo nodo/cromo durante 6 meses np. Node tiene una versión LTS de todos modos y Chrome no cambia mucho de lo que he notado. Imo, el beneficio de ahorrar 100 MB en cada instalación de la aplicación compensa los pequeños aumentos de velocidad de vez en cuando una vez que sale una nueva versión de Chromium / Electron. Además, una vez que tengamos a los desarrolladores a bordo, no debería ser demasiado difícil reducir el tiempo entre nuevas versiones del tiempo de ejecución. Entonces podríamos admitir la última versión del tiempo de ejecución y una o quizás dos más antiguas.

Reconstruir los archivos .node cada 6 meses tampoco debería ser demasiado difícil, supongo.

Electron-builder admitirá una nueva opción para todos los objetivos nsis: useSharedElectronRuntime. Por ahora, todas las dlls existentes serán, creo que es posible reducir el tamaño de exe y mover el código a dll, pero se puede hacer más tarde, ahorrar 30Mb ya es una buena meta.

1. Cree un ensamblaje firmado para todos los dll de electrones y publíquelos en las versiones de GitHub (bintray no es una opción, porque no es confiable).
2. El instalador de Nsis descargará e instalará el ensamblaje si aún no está instalado. Seguridad: el ensamblaje está firmado. Electron-builder también admite la instalación por máquina. Y Windows proporciona un nivel adicional de seguridad si se instala el ensamblaje por máquina, por lo que, si es necesario, puede habilitarlo. Se añadirá la opción adicional de instalar montaje por máquina en cualquier caso. Aún no está claro: ¿debería ser verdadero o falso de forma predeterminada? Creo que es falso, para asegurarme de que, por defecto, la aplicación electrónica se puede instalar sin administrador.
3. no hay necesidad de preocuparse por el tiempo de ejecución de electrones no utilizados: el dll compartido admite el recuento de referencias. Al desinstalar la aplicación, se eliminará el ensamblado y Windows lo eliminará si ya no lo usan otras aplicaciones.

@CiriousJoker Re: seguridad. No estaba pensando en problemas de seguridad si la aplicación en sí es maliciosa. Estaba pensando en aplicaciones electrónicas que absorben y usan contenido que no es de confianza. es decir, cada vez que una aplicación electrónica muestra una página web desde la web abierta en un webview o similar.

Muchas aplicaciones no se exponen a la web abierta, y estarían bien ejecutándose en un electrón más antiguo. Pero el otro extremo es algo así como Brave que como navegador web no hace más que exponerse. :-)

@sedwards2009 Sí , pero si empezamos a preocuparnos por todos y su madre, no progresaremos. Siempre habrá razones para no hacer algo. No contar con el 100% de los desarrolladores a bordo es solo un sacrificio que tenemos que hacer. Si realmente necesitan/quieren la seguridad, pueden tenerla manualmente.

En cuanto a elegir un LTS, la elección más sensata en mi humilde opinión es unirnos a Nodejs LTS, es decir, cualquier versión de electrón que corresponda al nodo LTS es efectivamente LTS de electrones. Esto podría traer cierta armonía y acuerdo para que podamos avanzar colectivamente y tener cierta seguridad en lugar de dejarlo como una elección libre (que niega esta comunidad) o una discusión (que no nos lleva a ninguna parte).

@CxRes Pero, ¿qué versión de Electron admitimos? En mi proyecto, el principal problema fue reconstruir los archivos .node contra la versión específica de Electron (no Node).

Podríamos configurar la versión más reciente de Electron como lts o usar la más utilizada.

¿Me estoy perdiendo de algo? Imo, el problema es Electron, no Node

Ok, déjame tratar de explicar esto de nuevo con un ejemplo:

• El nodo LTS está actualmente en 6.11.1
• Por lo tanto, queremos usar la versión más alta de electrón que se construyó oficialmente con la versión más alta de nodo que cumple la condición <=6.11.1>=6.0.0
• La versión más alta de electrón construida con el Nodo 6 es la electrón 1.4.15, que está construida con el Nodo 6.5.0
• Entonces, electron 1.4.15 es donde bifurcamos electron LTS y lo reconstruimos con 6.11.1 (y así sucesivamente hasta que haya nuevas versiones de Node v6)

Cuando Node LTS se mueva a v8 (LTS son solo números pares), juntos migraremos a un electrón aún no liberado que se construirá usando Node v8 o permaneceremos en la bifurcación LTS actual hasta que se lance dicha versión de electrones.

¿Qué pasa con los desarrolladores que quieren lo último y lo mejor?

@CxRes @CiriousJoker Evitemos salir del tema aquí. Ninguna razón técnica impide el uso de diferentes versiones de Electron. La fragmentación será en cualquier caso (el desarrollador lanzó la aplicación hace un año y la olvidó, otra aplicación de otro desarrollador la lanzó recientemente y usa otra versión).

@YurySolovyov Toda la idea de LTS es que no es lo último y lo mejor: es estable. Y si no podemos ponernos de acuerdo en centrarnos en una solución, estamos condenados a sufrir el subóptimo de Pareto de no tener ningún tiempo de ejecución porque ningún grupo tiene el tiempo y la capacidad para reconstruir cada versión y detectar errores.

También vea el comentario de @CiriousJoker arriba:

sí, pero si empezamos a cuidar de todos y de su madre, no progresaremos.

@develar Vale. Pero como usted señala, esto no es un problema técnico, es político (llegar a un acuerdo sobre una construcción que funcione para la mayoría de las personas de manera consistente, de modo que la carga se comparta).

Entonces, ¿qué hacemos ahora? ¿Elegimos una versión lts y comenzamos o tratamos de encontrar una solución para que funcione para todos al intentar construir un tiempo de ejecución único para todos con dll modulares (como sugiere @develar si entendí correctamente)

@CiriousJoker Ensamblaje lado a lado para una versión electrónica particular. por ejemplo ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 .

@develar No puedo encontrar esa cosa de electronruntineassembly en Google, ¿podría proporcionar un enlace o algo?

Imo, para acelerar las cosas, deberíamos elegir una versión aleatoria de Electron como la versión lts y comenzar. Podemos cambiar la versión de todos modos en cualquier momento más adelante.
@develar Todavía no sé a qué te refieres con ese ensamblaje en paralelo, pero tiene que funcionar en varias plataformas e imagino que también podemos implementarlo más adelante.

Nosotros (o en realidad ustedes) hemos estado hablando de esto durante años, pero si nadie comienza, nada cambiará y nos sentaremos aquí durante otros 3 años discutiendo ideas y encontrando formas de no comenzar.

Espero que los desarrolladores de electrones puedan resolver la separación del entorno de ejecución y la aplicación lo antes posible, lo que promoverá en gran medida las aplicaciones de electrones y veré un futuro brillante.

No lo resolvieron durante lo que me parecen años, así que soy un poco pesimista al respecto. Claro, sería increíble, pero ¿están trabajando activamente en ello?

@CiriousJoker Como se indicó anteriormente, estoy trabajando en el soporte de tiempo de ejecución de electrones compartidos para Windows en el generador de electrones. Presenté https://github.com/electron-userland/electron-builder/issues/1942 para seguir el progreso. Espero que esté listo para usar en 1 mes.

@develar Mi error, debe haberlo pasado por alto. En ese caso, buena suerte, ¡sería increíble si pudieras hacerlo!

Si alguien está interesado en la deduplicación de fragmentos definidos por contenido del subarchivo mencionada anteriormente en el hilo en https://github.com/electron/electron/issues/673#issuecomment -157980607, lo he abierto: https:// github.com/ronomon/deduplicación

Este largo hilo ha estado inactivo durante los últimos meses, pero creo que aún vale la pena investigar el problema que aborda. Durante el fin de semana hice una utilidad pequeña y mínima de una página para renombrar archivos en masa. Repleto de generador de electrones, el archivo .app final de Mac tiene 121 MB...

Estuve pensando en este problema últimamente. Luego eché un vistazo a mi teléfono inteligente: la aplicación de Facebook tiene un tamaño de 600 MB. Chrome tiene un tamaño de 325 MB, Mesenger tiene un tamaño de 300 MB... Entonces, una aplicación de 120 MB en el escritorio, realmente no me importa...

El tamaño no es un problema hoy en día. RAM y el consumo de energía es.

_editar: si no está de acuerdo, siéntase libre de compartir por qué_

Para la plataforma Windows, los esfuerzos de @develar con electron-builder (electron-userland/electron-builder#1942) parecen estar cerca de lograr un tiempo de ejecución compartido.

También noté que el catálogo web de aplicaciones, que empaqueta aplicaciones web como aplicaciones Electron independientes, resolvió el problema del uso de un tiempo de ejecución compartido para reducir enormemente el tamaño de la aplicación: webcatalog/webcatalog/issues/171. Se hizo en su empaquetador, mediante la vinculación de recursos compartidos entre aplicaciones .

Las aplicaciones web progresivas (PWA) son una solución parcial a este problema. En Android, puede agregar PWA a la pantalla de inicio y actuará como una aplicación real. El equipo de Chrome ahora está trabajando para habilitar la instalación de PWA en el escritorio (http://www.androidpolice.com/2017/12/05/google-wants-progressive-web-apps-replace-chrome-apps/), Microsoft también muestra interés en admitir PWA (https://www.windowscentral.com/faq-progressive-web-apps-windows-10) y espero que Firefox y Safari se pongan al día pronto. Las API que faltan (por ejemplo, el acceso al sistema de archivos nativo) se agregarán si los desarrolladores muestran interés.
La mayoría de las aplicaciones de Electron basadas en la web se pueden convertir fácilmente a PWA, pero no estoy seguro de las que son como Atom, VSCode; es probable que el código nativo deba reescribirse en WebAssembly.

@develar tiene algún progreso sobre esta idea?

¡Lo usaré cuando se lance!

Habiendo encontrado esto recientemente, solo quería dar mi opinión. Sin embargo, no he leído el número completo, por lo que puedo repetir algunas cosas sin saberlo.

Creo que algo como esto es muy importante, ya que aunque el tamaño de un programa Electron puede no parecer tan importante ahora, realmente comienzas a verlo cuando distribuyes un programa muy simple y pequeño, por ejemplo, una calculadora personalizada. En el caso de esto, algo como 5-10 MB sería razonable. Sin embargo, 60 MB o más sería simplemente ridículo. Para un programa más grande, el tamaño de Electron se vuelve más ignorable, pero aún puede ser molesto.

Sin embargo, dicho modo de tiempo de ejecución requeriría algún tipo de sistema de lanzamiento LTS considerando la tasa actual de lanzamientos. Luego, se podría alentar a los desarrolladores a depender de una versión LTS, e incluso se podría mostrar una lista de las versiones más comunes en uso en el directorio de aplicaciones, alentándolos a usar la más común a menos que carezca de una característica requerida.

El modo de tiempo de ejecución en sí mismo debería, en mi opinión, tener un sistema incorporado para instalar otras versiones de la biblioteca Electron también, de modo que si el usuario solicita instalar una aplicación que requiere una versión diferente, el programa de tiempo de ejecución puede descargarlo automáticamente como un simple paso dentro del proceso de instalación.

Creo que también se debe tener en cuenta que el uso de RAM de las aplicaciones Electron también podría mejorarse con la ayuda de esto, aunque los cambios necesarios para ponerlo en práctica serían mucho más importantes. Con un tiempo de ejecución compartido, las aplicaciones de Electron que usan la misma versión podrían compartir algunos recursos dentro de la memoria.

De todos modos, soy muy nuevo en todo el origen del proyecto Electron, así que lo siento si algo no quedó claro o si repetí algo innecesariamente. Sin embargo, realmente espero que esto se implemente, ya que realmente haría de Electron una plataforma mucho más prometedora para más tipos de programas. :+1:

@octacian Estoy empezando a pensar que las PWA son una mejor opción. Sin embargo, no es universal, no puedes hacer _todo_ usando PWA, pero ciertamente para cosas como calculadoras personalizadas, deberían ser más que suficientes.

Ahora solo tenemos que esperar a que surja el soporte de PWA en el escritorio .

También creo que con un sistema de este tipo, 1- será más fácil enviarlo a sistemas integrados/más pequeños, y 2- en el futuro se puede crear una base de sistema operativo similar a un electrón para dispositivos móviles.

@yasinaydin Ya existe LG WebOS. (Solía ​​​​haber Firefox OS también, pero está descontinuado)

@KeitIG ​​Mi señor, su argumento sería absolutamente decente si el único problema con Electron fuera su tamaño. Tener un programa un poco más grande pero simplificando la complejidad y la posibilidad de fallas para los desarrolladores (no podemos negar que Electron es excelente para brindarles a los desarrolladores una forma estandarizada de crear aplicaciones sin mucho espacio para equivocarse) sería increíble. Por desgracia, usar una versión separada de las bibliotecas para cada aplicación también significa un mayor uso de RAM y problemas de seguridad distribuidos (y más difíciles de solucionar). Lo expliqué mejor en mi problema duplicado , pero en pocas palabras, realmente creo que una biblioteca de tiempo de ejecución compartida que puede actualizar por sí sola y compartir entre diferentes aplicaciones de Electron (que también se enviaría en una versión "lite", algo así como cuando algunos desarrolladores solían distribuir archivos Java para usar en su JVM y empaquetaban .exe s) realmente sería el factor decisivo para Electron, y aunque entiendo que probablemente sería una gran cantidad de trabajo, me entristece que aún no está en los planes de los desarrolladores. Esperemos que lo hagan en el futuro.

@dre-hh Si bien reconozco la buena intención de su propuesta, es, entre otras cosas, demasiado restrictiva. Por ejemplo, he desarrollado una aplicación electrónica comercial para mi empleador y se usa en entornos altamente regulados (sin conectividad a Internet, requisitos de trazabilidad/auditoría, etc.). Nuestros clientes no pueden permitirnos hacer cosas como actualizar automáticamente el software. Es un mundo muy diferente al de las típicas aplicaciones web para las masas. Los navegadores Evergreen y la instalación automática de actualizaciones de seguridad del sistema operativo son, en mi opinión, una gran idea para la mayoría de las personas en la mayoría de los casos, pero mi punto es que no encajan en todas partes. A veces, el riesgo de interrupción causado por el cambio de software es mucho mayor que el riesgo asociado con la ejecución de una versión desactualizada del software, especialmente en entornos controlados donde existen otras técnicas de mitigación de seguridad. Por lo tanto, tomar una medida extrema, como bloquear la ejecución de aplicaciones que utilizan versiones obsoletas de electron (o, en realidad, cualquier biblioteca), no es una solución ideal, si es que lo es. (Además, los administradores ya tienen muchos controles para restringir qué programas se pueden ejecutar, por lo que podrían implementar esto sin ninguna característica nueva del sistema operativo).

Además, como ocurre con la mayoría de las preocupaciones de seguridad, gran parte del problema se debe a que los desarrolladores desconocen los riesgos o han elegido, por cualquier motivo (p. ej., falta de tiempo), no seguir las pautas de seguridad de las herramientas que utilizan. (por ejemplo , seguridad, capacidades nativas y su responsabilidad ) Nosotros, como desarrolladores, todos debemos hacer nuestra parte para asumir la responsabilidad de la calidad (que incluye la seguridad) de nuestro trabajo.

Finalmente, creo que es un error buscar una entidad de software comercial, como Microsoft, para abordar estas preocupaciones. Esto se debe en parte a que, como se acaba de señalar, no podemos esperar producir aplicaciones seguras a través de desarrolladores que no son conscientes de la seguridad. Más importante aún, al menos en mi opinión, es que una de las cosas hermosas de Electron es su naturaleza de código abierto y multiplataforma, que generalmente no son prioridades altas para los proveedores de software comercial. El progreso bien pensado y exitoso probablemente requerirá cierto nivel de consenso y esfuerzo de toda la comunidad de desarrolladores. Por supuesto, se agradecen las contribuciones de entidades comerciales.

@jacobq En caso de que no lo supiera, Microsoft es el propietario de Electron.

En caso de que no lo supieras, Microsoft es el propietario de Electron.

@ Jop-V Agregue una cita para esto; No creo que eso sea correcto. La página principal de electronjs.com dice:

Electron es un proyecto de código abierto mantenido por GitHub y una comunidad activa de colaboradores.

Microsoft es un consumidor de Electron (lo usa en productos como Visual Studio Code) y (supongo) también un colaborador, pero no tienen propiedad. El archivo de licencia no menciona a Microsoft ni el artículo de Wikipedia sugiere que tengan una posición de propiedad.

@jacobq Microsoft va a adquirir GitHub, por lo que si GitHub mantiene actualmente a Electron, Microsoft pronto lo mantendrá, por lo que puedo decir.

https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/

https://blog.github.com/2018-06-04-github-microsoft/

La adquisición de Github por parte de Microsoft no significa nada para Electron. Github es/será todavía una compañía separada, con sus propios productos y proyectos. No veo a Microsoft tomando la propiedad de Electron, tanto como no veo a Microsoft tomando la propiedad de Atom.

Sin embargo, creo que este debate no está ayudando realmente al punto inicial del problema.

https://github.com/GoogleChromeLabs/carlo

Carlo parece bastante intrigante. Le di una vuelta y es muy intuitivo. ¿Alguien ha experimentado con pkg ing todavía?

¿Por qué nunca se trabaja en todas las propuestas para reducir la sobrecarga de disco duro y memoria de los usuarios finales? Esta es una idea fantástica que tiene 4 años y todavía es solo una idea. No puedo entender por qué este tipo de cosas no están en la parte superior de las prioridades del proyecto.

@danielo515 porque en lugar de crear otro proyecto laborioso, existe https://github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app

¿De qué estás hablando? Esto ya es un proyecto enorme. También es el más extendido y utilizado, por lo que no me parece correcto señalar a las personas a un proyecto diferente para una característica que debería ser parte de este.
Además, Carlo es un enfoque diferente, usan tu Chrome instalado, por lo que no es como una versión daemon de Electron.

No puedo entender por qué este tipo de cosas no están en la parte superior de las prioridades del proyecto.

Porque hacerlo realidad es difícil (como "realmente" difícil).

Si no está satisfecho (lo cual es totalmente comprensible), siéntase libre de bifurcar a Electron y enviar un PR.

No me malinterpreten, si hubiera una solución fácil para este problema, estoy seguro de que ya se habría implementado.

@danielo515

... señalar a las personas a un proyecto diferente para una característica que debería ser parte de este no me parece correcto.

Creo que el punto es que cada proyecto tiene sus fortalezas y debilidades, y Carlo es ideal para casos con limitaciones de espacio. Para mis casos de uso, un tamaño de aplicación de 100 MB está perfectamente bien, por lo que, aunque me encantaría ver esta función, las otras funciones electrónicas son mucho más importantes para mí.

@jacobq Sí, tiene razón: diferentes casos de uso requieren diferentes herramientas.

Si alguien más está interesado, creé una lista de herramientas similares para desarrollar aplicaciones js en el escritorio.

https://github.com/styfle/awesome-desktop-js

Simplemente no uso Electron porque no puedo permitirme actualizar docenas de aplicaciones de 100 MB, y ya sabes cómo se deben actualizar las aplicaciones (tengo otras opiniones al respecto, pero compartirlas no ayudará).
Lo que realmente me gusta del enfoque de carlo es la idea de usar el navegador instalado.
Aún mejor, seguramente carlo podría usar cualquier navegador disponible, no solo chromium, ya que titiritero también puede manejar otros navegadores. En OSX generarías Safari, en linux epiphany (webkitgtk) o firefox, etc...
Entonces, para obtener una aplicación, solo tendría que instalar nodejs y su aplicación.
Ahora la pregunta será: ¿qué tan bueno puede ser pkg usando librerías instaladas en el sistema y complementos nativos?
Por ejemplo, si tuviera que empaquetar la aplicación que estoy desarrollando actualmente, necesitaría postgresql, sharp (y vips), webkitgtk y exiftool. Me gustaría poder distribuir la aplicación solo a usuarios de linux debian, fedora o ubuntu. Me gustaría salirme con la mía con los "paquetes locos" y, en cambio, capitalizar el arduo trabajo realizado por esas distribuciones, de forma gratuita.

@kapouer ... usa el navegador instalado...

Si bien en teoría es una buena idea, resulta en una mayor dificultad para codificar aplicaciones en el lado web, ya que ahora tendría que concentrarse en la compatibilidad con varios navegadores y los navegadores a los que recurren pueden estar limitados en lo que desea hacer, ya que no tiene soporte completo para cosas como las que puede encontrar en Chromium. También confía en que el usuario se asegure de que su navegador esté actualizado y que los múltiples proveedores de navegadores no rompan su aplicación con una actualización.

Muchos usuarios se las han arreglado para tener actualizaciones masivas de 50 Mb cambiando a actualizaciones delta o haciendo que los administradores de paquetes solo actualicen el archivo .asar o las carpetas de recursos. Y solo haz una gran actualización de Electron cuando sea necesario. Esto es lo que hacemos en nuestra empresa y ha funcionado muy bien.

Desde la perspectiva de un usuario ingenuo, el uso de la aplicación Shell de Electron como tiempo de ejecución compartido haría que sea realmente fácil de distribuir y usar. Por ej. Con 5 aplicaciones electrónicas en un solo sistema, tiene 5 instancias de shell de aplicación y ocupa alrededor de 300 MB, ¿verdad?

Creo firmemente que electron es el futuro de la UX de escritorio y este sería un gran paso (mira .NET Runtime; puede ser una mala comparación, pero es genial, ¿verdad?) para hacer que la tecnología web sea más poderosa.

Electron ya tiene un tiempo de ejecución para uso de desarrollo, ¿no es así? El "electrón". mando, quiero decir. ¿Por qué no reutilizar eso para el lado del usuario?

Para manejar múltiples aplicaciones dependiendo de las diferentes versiones de Electron, puede usar el enfoque que usa .NET core. Simplemente tenga varias versiones del tiempo de ejecución instaladas una al lado de la otra y haga que las aplicaciones declaren la versión mínima (o máxima) que requieren.

Hice un lanzador de prueba de concepto: https://github.com/ProPuke/electron-shared

Ejecutable único, de menos de 1 MB de tamaño. Pásele un directorio de aplicaciones o un paquete asar y comprobará los requisitos de su versión electrónica en su paquete.json devDependencies y descárguelo/ejecútelo con la versión correcta.

Los tiempos de ejecución de Electron se almacenan en AppData\Local\Local\electron-shared (windows) .cache/electron-shared (linux) Library/Application Support/electron-shared (mac) para que puedan compartirse entre aplicaciones.

Sin una ruta especificada, ejecutará automáticamente el directorio app o app.asar si existe; Entonces podría distribuir su aplicación solo con este archivo y app.asar . O esto podría asociarse con archivos .asar y solo se podrían distribuir los asars.

También tiene algunos parámetros de línea de comandos, incluidos --downloadOnly y --silent , por lo que se puede llamar desde los instaladores durante el proceso de configuración.

No maneja la actualización automática (solo se descarga si una versión compatible de Electron aún no está disponible en su máquina), pero esto podría hacerse periódicamente en el inicio o por un servicio en segundo plano (siempre que los tiempos de ejecución estén en el lugar correcto donde encontrará y usará lo último cuando se inicien las aplicaciones).

Saber cuándo eliminar las copias antiguas de los tiempos de ejecución puede ser complicado. Podrían acumularse con el tiempo. Tendríamos que realizar un seguimiento de qué aplicaciones instaladas usaron qué versiones (y, por lo tanto, cuáles ya no eran necesarias) o tal vez simplemente almacenar una fecha de último uso para cada versión de tiempo de ejecución y eliminarlas automáticamente si no se han usado. en un momento.

De todos modos, una prueba de concepto/propuesta. ¿Algo como esto resuelve problemas? ¿Me he perdido algo evidente y obvio?

Probé el electron-shared de @ProPuke y pude ejecutar la demostración de inicio rápido de electrones . Pero no pude ejecutar ninguna de las aplicaciones descritas en el sitio web de electronjs (porque la mayoría de las aplicaciones usan algún script de shell para iniciar la aplicación y no solo package.json, según tengo entendido). Pero creo que esta _prueba de concepto/propuesta_ podría ser un indicador de la próxima gran actualización.

Tengo una idea. electron Porque actualmente es compatible con el comando "electron.exe path". Creo que puedes abrirlo llamando a múltiples asars desde la línea de comando. En este momento, solo soy una idea. Espero que alguien pueda hacerlo, porque acabo de mencionar este software.
_____________ versión de traducción al chino__________
Tengo una idea. Porque actualmente electron admite el comando "ruta de electron.exe". Creo que se puede abrir usando la línea de comando para llamar a múltiples asars. Solo soy una idea en este momento, espero que alguien pueda echarle un vistazo, porque acabo de estar involucrado en este software.

Después de una mirada superficial a toda la conversación (y otras discusiones como Múltiples "aplicaciones"), resumiré: llamar a múltiples asars de forma nativa en lugar de comenzar con múltiples binarios tiene una larga historia, pero no es compatible. Pero la aplicación predeterminada de electron se implementa usando la línea de comando (tal vez, no lo sé por el momento). Creo que llamar a cmd a través de electrones (parece ser posible) debería poder lograr la compatibilidad de esta función.
Echando un vistazo superficial a todas las conversaciones (y otras discusiones, como Múltiples "aplicaciones"), concluyo que las llamadas nativas a múltiples Asar en lugar de múltiples binarios comienzan, lo que tiene un largo historial, pero no es compatible. Pero la aplicación predeterminada de Electron es una implementación que aprovecha la línea de comando (y, tal vez, no lo sé por un tiempo). Quiero llamar a cmd a través de electron (como si pudiera) debería poder lograr esta barra de compatibilidad de características.

En el peor de los casos, tendría que crear un archivo .bat o el equivalente para sistemas operativos que no sean Windows y ejecutarlo desde Electron.

Enlaces posiblemente útiles:

https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options
https://www.freecodecamp.org/news/node-js-child-processes-everything-you-need-to-know-e69498fe970a/

9718

https://stackoverflow.com/questions/50491092/execute-a-cmd-line-with-electron-angular
https://github.com/martinjackson/electron-run-shell-ejemplo

Parece que solo cuando no hay app.asar o carpeta de aplicaciones es el comando electron. ruta exe válida

Oh, entonces necesitas tener un electrón para ejecutar la ruta exe dentro del electrón usado para configurar todo eso. Todavía mejor que una instalación de electrones para todas y cada una de las aplicaciones utilizadas. Solo necesitaría una instalación de electrones para cada versión de electrones que necesite su aplicación. Probablemente necesitará crear una extensión separada que es un archivo zip renombrado que contiene tanto la aplicación que estamos tratando de ejecutar como un archivo con la versión recomendada (lo ejecutaría de inmediato), versiones compatibles (le preguntaría si ejecutar o instalar la versión recomendada y también descargar la versión Electron recomendada en segundo plano), o simplemente mostraría una barra de progreso de descarga, para que se descargue la versión recomendada.

O entendí mal algo.

Esta idea es probablemente la misma: dado que bat es actualmente fácil de decir, tómalo por ejemplo, el contenido es electron.exe app1.asar, después de la ejecución, electron abre el contenido de app1.asar. Probablemente así es como funciona, pero cuando escribes la siguiente oración, electron.exe app2.asar, en bat, solo puedes hacerlo cuando finaliza el electron de app1.asar. Y cuando se apaga el bate, se apaga el electrón. Pero escribo electron.exe app3.asar|electron.exe-v o electron.exe app3.asar|start, y así sucesivamente. Cuando cierro el bate, el electrón puede sobrevivir, pero no puedo seguir abriendo otros asars. Creo que este programa independiente podría ser mejor que este, porque bat todavía es algo limitado.

No si usa carpetas temporales.

Tiene las versiones (archivadas o no archivadas) en una carpeta electron_versions, desde la cual usa la versión recomendada o la versión compatible más nueva que ha descargado copiando la versión que está usando en una carpeta temporal, y después de terminarla, eliminar la carpeta.

La ruta de los archivos guardados localmente estaría en la carpeta electrónica o junto al archivo que está utilizando. Si lo está utilizando desde un archivo que contiene las cosas que mencioné en las últimas 24 horas, entonces tendría que volver a mover los archivos de datos guardados al archivo, o no moverlo en absoluto antes de eliminar esa carpeta de instancia electrónica temporal.

SSD?

???

El motivo para eliminar la carpeta temporal de electrones es que, en teoría, la aplicación podría cambiar los archivos de la instalación de electrones en la que se están ejecutando, y por diseño. Quiero decir, el archivo puede contener los archivos y carpetas que deben escribirse o sobrescribirse dentro de la instalación electrónica temporal.

Entonces, después de usar la instalación, la aplicación que ejecutó puede tratarla como dañada, por lo que no se puede reciclar y, por lo tanto, debe eliminarse. Sin embargo, la versión a partir de la cual se usó como base la instalación entonces corrupta todavía está intacta, en la carpeta electron_versions de la aplicación de tiempo de ejecución-electron que estamos tratando de hacer.

En realidad, si el archivo con extensión distinta, que mencioné antes, es de solo lectura, los datos que usa podrían moverse a %appdata%, teóricamente. Entonces, una aplicación que se ejecutó dentro del modo de tiempo de ejecución de electrones que estamos tratando de hacer en realidad sería portátil (autónomo) y, por lo tanto, copiar ese archivo sería suficiente para llevar la configuración de esa aplicación con usted.

Pero probablemente también necesitaríamos agregar una función de actualización para ese tipo de archivo, que sería otra instalación electrónica que copiaría y sobrescribiría los archivos del nuevo archivo de instalación a una copia del archivo de instalación anterior, y devolvería el nuevo archivo de instalación con el datos que tenía. Todo podría hacerse automáticamente, si hay un enlace de descarga en los archivos usados ​​por el runtime-mode-electron que estamos tratando de hacer.

Una vez que esté listo, si desea hacer un esfuerzo adicional, incluso podría agregar un cliente git desde el cual actualizar las aplicaciones, aunque eso podría requerir el uso de github y bitbucket para alojar archivos compilados.

puede usar el archivo de descarga "curl, wget, aria2c", y el usuario no puede necesitar instalar git, oh, necesita usar "gzip, 7z" desempaquetar zip。

Estoy creando una herramienta electron-runtime que funciona de manera similar a electron-builder . Incluye solo el archivo app.asar con un simple script sh (más tarde, será una interfaz de usuario para mostrar el progreso de la descarga de Electron). Actualmente solo funciona para macOS.

Cuando se ejecuta una aplicación empaquetada con electron-runtime , básicamente descarga una versión principal correspondiente de Electron, pero la más reciente en caso de versión menor y parche, ya que los cambios importantes de Electron ocurren solo en incrementos de versión principal.

La aplicación electron-quick-start tiene solo 62 KB, captura de pantalla:

Si te interesa, deja una estrella, relaciones públicas o un problema.

Actualicé un poco el paquete, que puede compilarse usando electron-builder ( aquí se describe cómo funciona ). ¡Así que ahora puedes construir incluso Visual Studio Code con él! (pero aún solo en macOS).

¡Lancé con éxito una primera versión de electron-global ! (Lo cambié, ya que se ha tomado electron-runtime ). Puede crear su aplicación usando mi paquete npm con electron-builder . También agregué una interfaz de usuario con una barra de progreso para mostrar el progreso de una descarga de Electron. Espero que se vuelva más popular para mejorar Electron.

Lo siento, uso el sistema Windows y no tengo dinero para usar MacOS. Pero creo que su proyecto tendrá mucho éxito.

@nwdxlgzs Es compatible con Windows, macOS y Linux...

Pensé que este proyecto solo era compatible con MAC.
Me voy a tomar un tiempo para probar este gran proyecto.

¡Gracias por hacerlo y por mantenernos al día!
También estoy usando Windows.
Echaré un vistazo al código cuando reciba el cambio.

Bueno, ¿qué tal integrar electron-global upstream y convertirlo en el nuevo valor predeterminado?