+100, ce serait très très utile pour réduire la taille de l'application.

L'extension .asar peut-elle être modifiée ? Ça sonne vraiment bizarre en hongrois. En gros, cela signifierait the shit dans le mauvais sens ( lien ).

.apak? avec tout le sérieux, il y a des tonnes de langues, donc presque toutes les extensions peuvent sembler bizarres dans certaines d'entre elles.

L'installation et la mise à jour du runtime IMO doivent être aussi simples que possible. De nombreux runtimes ont des notifications très ennuyeuses. En outre, si vous envisagez de le faire, certaines métadonnées de manifeste supplémentaires doivent être fournies, car les versions les plus récentes de l'application peuvent ne pas fonctionner sur l'ancien runtime. packages ), puis si le runtime doit être mis à jour, rendez ce processus aussi simple que possible. Je ne sais pas ce qui est facile pour la plupart des gens, mais pour moi c'est juste une fenêtre avec une barre de progression ou des messages d'état ("Téléchargement... 57%", "Mise à jour...")
Je ne suis pas sûr, mais des mises à jour en arrière-plan peuvent également être envisagées. Il peut s'agir d'un service de mise à jour ou simplement d'un téléchargement d'exécution pendant l'exécution de l'application et d'une mise à jour lorsque l'application se ferme.

+1 pour ça. Je travaille sur une application que je dois livrer pour mac et windows, et cela simplifierait considérablement la livraison.

Ce serait génial !

Quelques réflexions :

• Comme @YuriSolovyov l' a dit, nous avons besoin d'un moyen de déclarer avec quelles versions de l'atom-runtime un asar particulier est compatible. De préférence, cela devrait également permettre de spécifier une version exacte, car cela réduit la charge de l'assurance qualité lors de la publication d'une application basée sur asar.
  
  
  
  • Pour prendre en charge cela, nous aurions besoin d'autoriser l'installation côte à côte de plusieurs versions de l'atom-runtime, potentiellement invisibles pour l'utilisateur.
  
  
  • Notez que cela est quelque peu en contradiction avec les idéaux de limitation de la taille des téléchargements. Cependant, une entreprise produisant plusieurs produits basés sur asar pourrait standardiser en interne afin que toutes ses applications utilisent toujours la même version.
  
  
• Vous n'avez pas mentionné la prise en charge de la mise à jour automatique d'atom-runtime sur Mac, mais ce serait _très_ utile.
• Plutôt que d'avoir des installations source uniquement sur Linux, il serait bon de prendre en charge l'installation/la mise à jour des binaires, à la fois via les packages .deb/.rpm ainsi que par une méthode qui ne nécessite pas de droits sudo pour l'installation (c'est-à-dire par utilisateur). Pour les runtimes installés par utilisateur, la mise à jour automatique serait également très utile.
• Y aurait-il un support pour maintenir à jour les fichiers asar installés - ou est-ce quelque chose qui devrait être implémenté indépendamment dans chaque application?

Enfin, quel est le calendrier de cet effort ? Quelle serait la meilleure façon de commencer, si je voulais commencer à mettre en œuvre certaines parties de cela ? Je suis ouvert à contribuer.

@ joshuawarner32 Actuellement, ce n'est qu'une idée approximative, je prévois d'y travailler après avoir résolu certains problèmes majeurs d'atom-shell, mais cela pourrait prendre des mois plus tard.

Je pense qu'il vaut également la peine de regarder les runtimes existants et comment ils fonctionnent/mis à jour, à quel point ils sont dérangeants et quels sont les autres avantages et inconvénients.

Actuellement, ce n'est qu'une idée approximative, je prévois d'y travailler après avoir résolu quelques problèmes majeurs d'atom-shell, mais cela pourrait prendre des mois plus tard.

Cela fait environ 5-6 mois. Ce serait formidable que cela soit implémenté.

Nous avons construit une implémentation interne de cela qui correspond très bien à notre cas d'utilisation particulier, et nous pourrions être en mesure de l'installer en amont. Le danger serait qu'il soit en fait trop spécifique à notre cas d'utilisation, et personne d'autre ne serait intéressé par la complexité supplémentaire.

Voici les points forts de notre conception :

• Déployer des fichiers .asar.gz pour plusieurs applications différentes sur un serveur
• Distribuez une seule version d'atom-shell aux utilisateurs, qui ne regroupe aucun code pour des applications spécifiques
• Au démarrage de l'application, téléchargez le fichier .asar.gz approprié (s'il ne s'y trouve pas ou s'il en existe un plus récent sur le serveur). Extrayez-le et exécutez l'application contenue.
• Notre build atom-shell accepte un argument --app pour spécifier quelle application télécharger/exécuter

Est-ce que c'est ce que les gens de l'atom-shell avaient en tête ? Est-ce que quelque chose comme ça serait utile à d'autres personnes?

Comme le JRE, il pourrait s'agir de l'ERE (electron runtime environment), avec des fichiers .eapp (electron app)

-1 pour .eapp

+1 J'en ai besoin !

Sous Windows, nous pouvons fournir un programme d'installation et un programme de mise à jour automatique pour atom-runtime, et enregistrer le type de fichier .asar à ouvrir avec.

Installez Steam sur Windows et découvrez comment ils créent des raccourcis de jeu, ils utilisent en fait un gestionnaire de protocole, c'est relativement intelligent

:+1 : sur le modèle Steam.

Il n'y a aucun obstacle technique à la mise en œuvre de cela, le tout peut simplement être une application Electron elle-même. Mais le problème est que ce n'est pas facile à mettre en œuvre non plus, en tenant compte de tous les détails, je pense que cela nécessite une petite équipe travaillant à plein temps dessus, je ne suis pas sûr que cela se produira un jour.

Mais le problème est que ce n'est pas facile à mettre en œuvre non plus, en tenant compte de tous les détails, je pense que cela nécessite une petite équipe travaillant à plein temps dessus, je ne suis pas sûr que cela se produira un jour.

Il y a beaucoup de questions dans mon esprit qui, bien qu'elles ne soient certainement pas insurmontables, rendent ce plan difficile. Par exemple, disons que "App 1" nécessite 0.30.x et ne peut pas fonctionner sur 0.31.x, et "App 2" nécessite le contraire. Qui gagne dans ce scénario ?

Cela semble demander beaucoup d'efforts et d'infrastructure / astuce pour optimiser quelque chose qui n'est pas notre plus gros problème - l'espace disque et la bande passante, au détriment de la complexité du développeur (c'est-à-dire que maintenant les développeurs doivent créer cet installateur de chaîne fou pour d'abord installer / vérifiez Electron, puis installez leur application)

Je ne veux pas haïr une idée ! Je pense juste qu'avec le temps que nous prendrions pour le faire, nous pourrions plutôt le consacrer à notre gros problème - rendre très facile pour les nouveaux développeurs de créer et de publier des applications Electron, de leur première ligne de code jusqu'à l'expédier aux utilisateurs

@paulcbetts Mais bon, ses avantages en valent la peine, n'est-ce pas ? Lors de la mise à jour d'une application, les utilisateurs devront télécharger moins d'un Mo au lieu d'environ 70 Mo. Ce qui signifie que nous n'aurons même pas besoin de frameworks de mise à jour automatique et tout, nous devrons simplement télécharger et extraire une archive micro-zip avec quelques fichiers.

J'ai passé les trois derniers mois dans une région éloignée où la vitesse était inférieure à 128kbps et croyez-moi, la taille de la mise à niveau est une énorme douleur dans le cul, le pire est qu'il y a encore des tonnes de personnes dans des situations similaires

Ce qui signifie que nous n'aurons même pas besoin de frameworks de mise à jour automatique et tout, nous devrons simplement télécharger et extraire une archive micro-zip avec quelques fichiers.

Je ne pense pas que ce soit vrai cependant, car il est presque certain qu'à un moment donné, vous voudrez passer à une mise à jour vers une version plus récente d'Electron, puis kerplowie, vous êtes dans une situation similaire (ou au moins une qui est tout aussi moche )

Les applications de base font maintenant entre 30 et 50 Mo, à moins que vous n'ayez une tonne de vidéos dans votre package. Je ne pense pas que ce soit un tronçon pour la plupart des gens à télécharger. Je crois qu'une vidéo YouTube moyenne fait entre 30 et 40 Mo...

Je voudrais juste faire une remarque ici, en Chine, la vitesse de connexion est en moyenne d'environ 20 Ko/s (étant entendu que j'ai une connexion plus lente que ~ 92 % de ma ville.) La mise à jour d'Atom/electron nécessite généralement une journée complète de wget -c 'ing. sauf si les miroirs taobao sont utilisés.

Pour la compatibilité des versions, le développement d'électrons va trop vite pour avoir une version fourre-tout non plus, peut-être qu'une sorte d'enveloppe/d'aide pourrait être utilisée pour utiliser/télécharger la version majeure demandée au démarrage de l'application ?

20 Ko/s ? comment pouvez-vous survivre? Je ne peux pas imaginer à quel point cela doit rendre les choses difficiles !

@steelbrain pas mon intention

@RIAEvangelist Se débrouiller rapidement et beaucoup de patience. La vitesse devient très rapide tard dans la nuit, alors laissez simplement les téléchargements en cours d'exécution ou programmés pendant que vous dormez. :3

Quoi qu'il en soit, je pense que ce ne serait pas trop de travail d'écrire un wrapper tiers (de base), quelqu'un veut-il essayer?

Les fichiers .asar, cependant, ne peuvent pas facilement déclarer leur version électronique. Peut-être faudrait-il un autre système de descripteur de programme ?

Que diriez-vous d'une sorte de répartiteur de version d'exécution qui (télécharge si nécessaire et) les lanceurs nécessitaient une version d'exécution pour votre application ? Nous pouvons ajouter une entrée à package.json pour cela.

@YuriSolovyov Sauf que nous ne pouvons pas avoir dit que le runtime gère les fichiers .json par défaut. Je suppose qu'il pourrait d'abord lire le fichier asar et afficher package.json, mais cela le ralentirait un peu.

@Tribex oui, le flux logique ressemble à :

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

Idéalement, le mode d'exécution devrait fonctionner comme Steam ou Chrome App Launcher . Le problème principal est de savoir comment nous gérons les applications lorsque les mises à niveau d'exécution vers une nouvelle version.

Les applications Electron souffrent de la mise à niveau d'Electron, en particulier des modules natifs de nœud. Les modules natifs doivent être reconstruits pour chaque mise à niveau d'Electron en raison du problème C++ ABI (il existe plusieurs problèmes de plantage oubliés et reconstruits signalés par les utilisateurs).

Steam ne souffre pas de la douleur puisque chaque jeu sur Steam est un programme autonome, en fait vous pouvez lancer le jeu sans Steam Client. Chrome App Launch ne fonctionne pas non plus, car les applications Chrome sont écrites en HTML/JS/CSS qui sont des types de langages interprétés, il n'y a pas d'écart dans les différentes versions de Chrome.

@hokein que diriez-vous d'avoir un "client" léger dans une langue maternelle, qui télécharge plusieurs langues, chaque fois qu'il rencontre une application qui dépend d'une version désinstallée d'électron, il en télécharge une copie, puis exécute chaque application avec son électron spécifique.

Il y a une nouvelle version d'Electron environ une fois par semaine, donc les chances que 2 applications aient exactement la même version d'Electron sont minces.

Pour prendre en charge une approche d'exécution, nous devrons probablement commencer à séparer les versions en versions LTS (support à long terme) et en versions de pointe. Le LTS sera pour la production et le bord saignant sera pour le développement et les tests. LTS n'obtiendra que des corrections de bogues et peut-être quelques modifications qui ne remplacent pas les principales versions de io.js et du shell de contenu, de sorte que les modules natifs devraient toujours fonctionner.

étant donné ce que @etiktin a dit, à moins qu'un utilisateur n'ait de nombreuses applications électroniques sur son système, il n'y aurait probablement aucun avantage en termes de temps de téléchargement, car il devrait toujours télécharger le temps d'exécution à chaque fois.

Au cours des deux semaines où j'ai regardé Electron, je pense avoir vu 4 versions.

@etiktin Idéalement, si electron suit semver, une application pourrait déclarer la version ^ 0.31 et utiliser la dernière version 0.31.x. Cela pourrait aider un peu les choses.

Nous avons une application en production avec un mécanisme de mise à jour automatique semver qui fait ce qui suit :

1. OBTENEZ un simple point de terminaison HTTP sur le serveur indiquant la version actuelle (0.3.0, 0.3.1, etc.) et la plate-forme (darwin-x64, win32-ia32, win32-x64, etc.) de l'application.
2. Le serveur renvoie "304 Not Modified" ou bien un manifeste JSON s'il existe une version plus récente.
3. Le manifeste JSON est essentiellement une liste imbriquée de dossiers, fichiers et liens symboliques dans la nouvelle version.
4. Une entrée de dossier dans le manifeste JSON ressemble à ceci : [nom, tableau d'entrées enfants].
5. Une entrée de fichier dans le manifeste JSON ressemble à ceci : [nom, hachage de contenu, tableau de hachages de contenu divisé en morceaux de 64 Ko, un indicateur entier indiquant si le fichier est exécutable ou non].
6. Une entrée de lien symbolique dans le manifeste JSON ressemble à ceci : [nom, chemin de destination].
7. Ces manifestes JSON sont créés et mis en cache sur le serveur pour chaque version. Pour chaque fichier du manifeste JSON, le serveur exécute un algorithme de déduplication simple pour diviser le fichier en morceaux de longueur variable à l'aide de la segmentation dépendante du contenu, puis hache les morceaux à l'aide de SHA256. Cela garantit que la plupart des hachages de blocs pour différentes versions du même fichier restent les mêmes, même si le contenu est décalé de quelques octets. La longueur moyenne des blocs est d'environ 64 Ko pour une efficacité de déduplication et de compression optimale. Si les morceaux sont plus gros, ils ne seront pas non plus dédupliqués, si les morceaux sont plus petits, ils ne seront pas aussi bien compressés. La longueur moyenne des blocs sera également augmentée pour les fichiers très volumineux afin d'éviter d'avoir trop de hachages de blocs dans les métadonnées.
8. Lorsque l'application reçoit un nouveau manifeste JSON du serveur, elle vérifie l'espace disque libre disponible et crée un nouveau répertoire temporaire avec un ID universel unique. En utilisant son ancien manifeste local comme point de départ, il copie ensuite les morceaux des fichiers locaux ou télécharge les morceaux manquants du serveur pour recréer le nouveau manifeste. Après avoir créé la nouvelle version, il vérifie ensuite la structure des répertoires et les signatures de tout le contenu des fichiers. Si quelque chose a été corrompu dans le téléchargement, il supprime la mise à jour.
9. Si la nouvelle mise à jour a été vérifiée avec succès par rapport au manifeste, elle lance ensuite la nouvelle version de l'application sur le nouveau chemin de mise à jour.
10. L'ancienne version remarque qu'une autre version est en cours d'exécution et s'arrête.
11. La nouvelle application attend que l'ancienne version se ferme, puis se copie dans un autre répertoire temporaire, renomme l'ancienne version en répertoire d'archive et renomme le répertoire temporaire à l'emplacement de l'ancienne version (/Applications/Ronomon.app). Il s'exécute ensuite à nouveau, mais maintenant à partir de l'emplacement de l'ancienne version (/Applications/Ronomon.app), puis nettoie le répertoire d'archivage.
12. Si quelque chose ne va pas pendant la transition, l'ancienne version reste sur le chemin canonique jusqu'à ce qu'elle soit changée par l'appel de renommage.

Dans l'ensemble, cela fonctionne très bien en production. La déduplication et la compression signifient que seulement 33 % environ doivent être téléchargés pour une mise à jour de version majeure typique et que les mises à jour mineures ne nécessitent que 1 à 2 Mo selon l'application. La mise à jour automatique gère Electron et le code de l'application comme une seule unité atomique et ne viole jamais aucune signature de code au cours du processus.

+1 À l'idée
+1 Pour renommer asar

Je suis descendu pour faire un problème à ce sujet. J'ai trouvé que ça existait déjà, alors je mets mon + :100: à ça
Nous avons totalement besoin d'une solution de type JRE ou .NET ou Adobe Air, car emballer le runtime avec chaque application les rend vraiment volumineux.

Des mises à jour sur le fait d'avoir un runtime séparé des applications ?

Est-ce fermé parce qu'une solution a été développée ?

@PierBover ce problème est ouvert.

ceci - https://github.com/KeitIG/museeks/issues/48 - a été fermé. dans le référentiel de quelqu'un d'autre.

Oh merci @championswimmer et désolé pour la confusion.

Alors, y a-t-il des nouvelles sur le runtime indépendant? Est-ce quelque chose sur lequel on travaille?

@PierBover , cela ne se produira probablement pas de sitôt en raison de la fragmentation de la version actuelle (il est difficile de trouver 2 applications électroniques qui utilisent exactement la même version). Peut-être après la sortie de la v1.

@jorangreef utilisez-vous votre mécanisme de mise à jour différentielle sur toutes les plateformes ? Ce serait génial si vous pouviez publier ce code en tant que module autonome.

@championswimmer Oui, j'ai réussi à créer un script de construction pour mon application, donc je peux maintenant distribuer mon application. Mais je garde un œil là-dessus car ce serait intéressant.

@etiktin Oui, la mise à jour automatique différentielle fonctionne actuellement sur toutes les plateformes. S'il incluait également un programme d'installation minimal qui effectue le téléchargement, le programme d'installation pourrait être partagé par plusieurs applications et utiliser une version en cache d'Electron si elle est déjà disponible. Cela servirait à rendre les installations beaucoup plus rapides. J'aimerais l'ouvrir en source si les gens sont intéressés, et j'essaierai de publier le code dans les prochains mois.

Par exemple, disons que "App 1" nécessite 0.30.x et ne peut pas fonctionner sur 0.31.x, et "App 2" nécessite le contraire. Qui gagne dans ce scénario ?

Ensuite, ils devraient installer les deux versions et il y aura deux runtimes, tout comme VS C++ 2008 coexiste avec 2005. J'aime vraiment la façon dont les runtimes VS C++ sont installés, le programme d'installation installerait une version requise s'il n'y en a pas, et d'autres peuvent dépendre de plus tard, et différents runtimes peuvent coexister. L'application des exigences de version semble également se faire plus facilement dans le programme d'installation.

@louy2 Il y a une différence entre l'exemple Visual C++ (3 ans entre les versions) et Electron (3 versions par mois au moins)

Je vais plaisanter avec une citation "c'est un système défectueux" ici, si la majorité des
les applications de l'écosystème Electron ne sont pas compatibles avec +- 0.0.1 ou
Différences de version 0.1.0

Le 20 février 2016 à 18h55, Pierre de la Martinière <
[email protected]> a écrit :

@louy2 https://github.com/louy2 Il y a une différence entre le
Exemple Visual C++ (3 ans entre les versions) et Electron (3 versions par
mois au moins)

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/atom/electron/issues/673#issuecomment -186595285.

+1

J'ai empaqueté electron dans un package .deb en utilisant fpm . Cela pourrait être un bon point de départ sur Linux (basé sur Debian ou RPM, au moins). Vous pouvez jeter un oeil ici : iamale/electron-deb ; également un exemple d'application est là . (Cela fonctionnera également avec asar, il suffit d'ajouter une entrée MIME dans le package d'exécution.)

Ce serait vraiment génial si nous avions aussi quelque chose comme ça sur les autres plateformes ! Je pourrais probablement essayer de l'empaqueter pour Windows, mais je ne l'utilise plus activement et je n'ai pas vraiment eu beaucoup d'expérience avec.

(Merci à @louy2 de m'avoir signalé ce fil !)

Au fait, quel est le type MIME pour .asar ? Est-ce que application/x-asar ferait l'affaire ?

@iamale Au lieu de fpm , avez-vous jeté un coup d'œil à AppImageKit . Le principal avantage que vous obtenez est qu'au lieu de créer plusieurs bibliothèques et tout, vous pouvez cibler toutes les distributions Linux avec un seul exécutable. Vous n'avez également plus besoin de demander à l'utilisateur d'installer des dépendances car elles sont regroupées avec l'exécutable. C'est un beau projet, jetez-y un coup d'œil.

et pour le mime, que diriez-vous de application/x-electron ?

@steelbrain C'est une bonne idée. Cependant, cela ne résoudrait pas le problème d'origine : le runtime Electron devrait être fourni avec chaque application (car les images doivent être autonomes), ce qui est exactement l'objet de ce problème. Bien que je pense qu'il devrait être relativement facile de créer des AppImages à partir d'applications Electron, et je pense que ce serait formidable lorsque la gestion traditionnelle des packages ne peut pas être utilisée (distros rares ou utilisateurs non privilégiés). Alors, merci de l'avoir signalé !

application/x-electron sonne bien au fait, je m'y tiendrai probablement.

Ajout du support asar ! Pas encore dans le référentiel, je le reconstruirai plus tard dans la journée ou peut-être demain. Pour l'instant, vous pouvez obtenir le package sur transfer.sh (le lien sera valide pour les 2 prochaines semaines)

Vous avez besoin d'un asar.json à l'intérieur du .asar, pour dire :

• version recommandée
• versions compatibles
  Une fois cela fait, vous avez besoin d'une application utilisant Electron (n'importe quelle version de celui-ci) pour rechercher sur le Web (1) des mises à jour pour lui-même (le vérificateur) et (2) les versions existantes sur votre ordinateur, puis si une version compatible existe, elle analyse le chemin d'accès au fichier .asar ouvert, sinon téléchargez la version recommandée et vérifiez à nouveau. L'application elle-même peut être écrite en Electron ou en python (car elle ne nécessiterait qu'une interface utilisateur minimale ou nulle).

L'idée est la suivante : l'application qui vérifie si la version électronique requise est téléchargée n'a rien à voir avec les versions électroniques nécessaires.

Si besoin est, vous pouvez mettre à jour le contenu de default_app, ainsi que le reste de l'application, à l'exception de celle-ci.

Et là-dedans, vous pouvez enregistrer les versions avec app.setPath("userData", __dirname + "/ElectronVersions"); , puis ces versions pourraient être laissées là seules et de nouvelles installées au besoin.

Au lieu de fpm, avez-vous jeté un œil à AppImageKit .

Il existe une AppImage d'Atom disponible sur https://bintray.com/probono/AppImages/Atom/_latestVersion#files - il suffit de télécharger, chmod a+x , et de l'exécuter sur n'importe quelle distribution Linux x86_64 pas trop obsolète.

Le problème n'est pas seulement Linux, nous avons besoin d'un moyen de le rendre inter-OS, ce qui signifie que nous devons pouvoir le faire fonctionner sur Linux, Windows et Mac OSx.

Une sorte de lanceur spécifique au système d'exploitation qui recherche si le runtime est disponible et à jour/compatible avec le package asar

(de nombreuses années plus tard) Permettez-moi de résumer la discussion :

1. @zcbenz propose un runtime qui gère les instances locales d'Electron afin que les packages .asar soient uniquement distribués et que le regroupement des binaires Electron soit évité. Le runtime gère également l'exécution des packages .asar .
2. @YurySolovyov suggère d'améliorer le fichier manifeste avec des informations supplémentaires (par exemple, la version Electron requise) afin que le runtime sache quelle version doit être utilisée pour quel package .asar . Un aperçu de cette approche est donné ici .
3. @ joshuawarner32 introduit l'idée de plusieurs versions d'exécution, d'un emballage binaire (par exemple, comme .deb ) et d'une mise à jour automatique pour les packages .asar . De plus , l'idée d'un serveur de distribution est envisagée.
4. @paulcbetts suggère de jeter un œil au modèle Steam et d'implémenter quelque chose de similaire. Il souligne les complications liées à l'idée d'un environnement d'exécution local prenant en charge différentes versions d'Electron, etc.
5. [les gens discutent de la vitesse d'Internet en Chine et de leurs affaires d'enfance]
6. @hokein souligne les complications lors de la mise à niveau du runtime. Spécialement wrt. modules natifs qui doivent être reconstruits avec les en-têtes Electron.
7. @etiktin veut avoir des versions LTS et à la pointe de la technologie afin que les applications prêtes pour la production utilisent LTS plutôt que la pointe de la technologie.
8. @Tribex dit que si nous nous en tenons au versioning sémantique , nous n'avons pas besoin d'avoir une instance locale de _all_ versions, mais seulement celles qui sont incompatibles.
9. @jorangreef fournit un exemple de système de mise à jour automatique différentielle déjà en production pour sa propre application.
10. @iamale a créé un package fpm d'Electron pour exécuter des packages .asar .

_disclaimer : j'ai essayé d'inclure uniquement les principaux points de discussion. Veuillez m'excuser si j'ai raté quelque chose !_

J'ai lu la discussion jusqu'ici, j'ai essayé de résumer les points principaux et j'ai voulu aborder certains d'entre eux. L'idée d'un environnement d'exécution avec des "intégrations de plate-forme profondes" va au-delà d'une simple instance locale. Un produit minimum viable doit être défini, qui agit comme un environnement d'exécution à l'échelle du système. J'ai également ajouté une fonctionnalité intéressante qui pourrait être utile. La dernière section décrit les modifications/fonctionnalités à implémenter.

Raisonnement:

Ce que font la plupart des développeurs (c'est-à-dire regrouper les binaires Electron) revient à lier toutes les bibliothèques partagées de manière statique ! C'est comme livrer un four avec chaque pizza que nous vendons.

MVP :

• Gestionnaire d'environnement : assure le suivi des instances Electron disponibles localement. Il peut être utilisé pour décider quel package est compatible avec quelle instance (en utilisant package.json amélioré [voir ci-dessous]). Il doit également prendre soin de définir les variables d'environnement correctes pour les packages à exécuter.
• Gestionnaire de mise à jour : la possibilité d'une mise à jour automatique (+ notification) et d'une mise à jour automatique différentielle a été discutée. Ce serait bien de l'avoir en tant que démon qui s'occupe de la mise à jour des instances locales vers les dernières versions.

Bon d'avoir:

• Gestionnaire de packages/dépendances : tout comme apm d'Atom , un gestionnaire de packages est nécessaire pour télécharger des packages .asar (depuis GitHub ou une URL donnée, etc.) et les installer localement (comparable à apt-get sous Ubuntu ou brew sous Mac).

Conditions:

• Fichiers manifestes améliorés : package.json doivent également contenir un semver (ou une plage de semver) pour indiquer quelle version d'Electron est requise.
• Procédure d'installation/désinstallation définie : ATM le package .asar contient tout le nécessaire pour exécuter une application. Il est cependant possible de ne livrer que les modules de dépendance source et download lors de l'installation. Si nous devenons trop courageux, nous pouvons avoir une sorte de répertoire _global_ contenant des dépendances pour toutes les applications (la structure plate de npm 3 pourrait aider). Ceci, cependant, peut devenir très compliqué, très rapide (par exemple lors de la désinstallation d'une application).
• Plusieurs runtimes locaux : si le versioning sémantique a été appliqué jusqu'à présent, il n'y a que deux versions incompatibles 0.x et 1.x . Les versions mineures et les correctifs doivent être rétrocompatibles, nous n'avons donc besoin que de la dernière version de 0.x et 1.x sur le système.

Inspiration :

• Gestionnaire d'environnement/dépendances : virtualenv de Python, virtualenv rbenv Ruby, et voir aussi ruby-build .
• Gestionnaire de paquets : pip de Python, pip apm Atom.
• Gestionnaire de mise à jour : le processus zygote de Chromium a une approche intéressante des mises à jour _silencieuses en arrière-plan_.
• Traducteurs de code (pour s'adapter aux nouvelles API) : Pythons 2to3 .

epm (gestionnaire de paquets électroniques) semble déjà être pris comme nom...
Peut-être appeler le runtime elec et les applications .tron ? Il y a probablement des problèmes de marque avec TRON mais ça sonnerait bien ;)

Peut-être uepm (gestionnaire universel de paquets d'électrons), puisqu'il est destiné à être exécuté sur tous les systèmes d'exploitation pris en charge par Electron ... ou epmc (centre de gestion de paquets d'électrons) et le fichier .epack (forfait électronique). L'extension, au moins, sonne mieux que .tron et ne peut pas être confondue avec un film ("Donnez-moi ce truc de tron, mec" _vous tend le film_).

Il existe également une foule de mots dans le domaine de la physique théorique liés à l'électron

• fermions
• lepton
• charger
• coulomb
• pauli

Et, pas directement lié, mais un peu plus en accord avec ce qui se passe avec un gestionnaire de paquets,

• boson
  ;)
  (je crois que le photon a déjà été pris)

@kapouer +quark ? je ne sais pas si c'est pris

Quark est pris, le reste je ne sais pas. Mais pourquoi devons-nous maintenir le statu quo, alors que cette liste de suggestions suggère de NE PAS maintenir le statu quo ? Mais puisque nous y sommes, pourquoi ne pas l'appeler Hauldron ? Prise du LHC. Collider n'est pas une bonne idée, c'est donner au produit une teinte négative, car son sens est étroitement lié à la guerre...

Particle(s) ? Assez long cependant.
Liste des particules dans le wiki

Bien que la dénomination soit importante, je pense toujours que nous devons d'abord étudier la sémantique d'exécution/mise à jour/packaging/distribution.

lepton semble parfait puisque c'est la famille de particules à laquelle appartient l'électron.

Une idée un peu hors de portée : un gestionnaire d'exécution plus générique serait encore plus génial (et pas vraiment plus difficile à mettre en œuvre). Par exemple, nous pourrions également inclure les fichiers binaires @nwjs et les gérer dans le même version-manager-thingy (tout comme @asdf-vm, mais pour les runtimes GUI).

Vite et sale : https://github.com/iamale/lepton. Ne prend en charge que la version fixe pour le moment (semver est la prochaine chose à faire) et les applications sont décompressées (c'est-à-dire pas encore de .asar-s).

Agréable!

+1

Même s'il n'y a pas de .asar, @iamale , tant que vous avez un moyen de savoir quel fichier ouvrir, je pense que ça devrait aller. Comme, par exemple, vous pourriez avoir un file.something avec un code json lié à package.json pour qu'il sache quoi ouvrir...

C'est une idée assez folle, mais qu'en est-il de l'utilisation du champ electron dans package.json pour faire
tout (enfin, pas comme TOUT, mais tout préparé) package npm exécutable?
Comme:

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

Cela pourrait être réalisé en ajoutant la possibilité pour electron d'installer des packages npm et de les rendre exécutables et visibles pour le système hôte.
Juste comme

electron install atom

Pour que cela fonctionne, nous aurions besoin de séparer la commande electron et les bundles d'exécution réels.

mais qu'en est-il de renommer le package.json en package.electron et d'avoir son contenu quelque chose comme ça ?

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"
  ]
}

Dans cet exemple, il recommanderait d'utiliser l'électron 1.2, s'il n'est pas trouvé, vérifie également s'il existe une version entre 1.2.1 et 1.2.5, sinon vérifie 1.3.1, puis 1.3.0.1, sinon il vérifie pour 1.1 et sinon, télécharge 1.2.

Peut-être qu'il pourrait y avoir quelque chose comme ça qui télécharge automatiquement la version recommandée, et s'il ne le peut pas, alors il vérifie les versions compatibles. Et prenez chacun de ceux qui sont compatibles et vérifiez-les, et si aucun ne fonctionne, demandez à l'utilisateur s'il ne veut pas utiliser une version incompatible, et s'il appuie sur no , il fonctionnera avec une version incompatible trouvé sur le PC, et si aucun n'est trouvé, au lieu de demander d'utiliser une version incompatible, affichez une fenêtre d'erreur indiquant qu'il n'y a pas d'installation Electron détectée.

@sapioit Avoir un manifeste séparé me semble être une bonne idée. Avoir une extension de fichier personnalisée simplifierait un peu les choses. (Bien que .electron semble un peu long.)

Peut-être d'après le lepton de @iamale , .lept ?

Je ne vois aucun avantage à ne pas utiliser package.json , le champ d'électrons fait la partie isolation. Babel et ESlint utilisent cette technique et s'en sortent très bien.
Cela facilite grandement la publication d'applications directement vers/via npm.

Ouais, j'appuie @YurySolovyov - je pense que le mettre dans le package.json est plus approprié

@YurySolovyov L'avantage d'un fichier supplémentaire est que le runtime peut enregistrer un gestionnaire pour l'extension du fichier supplémentaire et s'exécuter automatiquement comme ouvreur par défaut du fichier. Alors que faire cela avec package.json nécessiterait d'enregistrer le gestionnaire pour chaque fichier JSON, ce qui serait pénible pour les utilisateurs.

@Tribex juste point.
Peut-être que package.electron peut être juste une sorte de lien qui indique au runtime "Hey, take a look at package.json, it should contain the info on how to launch it" . C'était une idée "folle", alors oui, je suis d'accord pour la peaufiner.

Je suis d'accord avec @tribex , nous avons besoin SOIT d'un fichier séparé, soit de renommer le package.json. à autre chose.

@wurysolovoyov vous ne pouvez pas faire ça. La seule chose que vous pouvez ouvrir un fichier est d'avoir une extension qui lui est attachée, auquel cas chaque extension s'ouvrira avec le même logiciel. Donc, à moins que vous ne soyez pas d'accord pour ne pas pouvoir ouvrir un .json avec autre chose que electron (ce qui entraînerait une erreur, à moins qu'une application électronique appropriée ne soit ouverte), vous pouvez toujours le faire, mais laissez-nous, ceux qui veulent pouvoir ouvrir les fichiers .json , pouvoir les ouvrir avec le programme avec lequel nous voulons les ouvrir.

Sinon, vous ne pourrez pas éditer le fichier, sans ouvrir d'abord l'éditeur ou sans changer ce qu'il faut ouvrir .json à chaque minute environ.

Je veux dire @YurySolovyov pas @wurysolovoyov

Peut-être que je ne l'ai pas dit clairement: le but de package.electron est uniquement de servir de marqueur que ce répertoire est une application, de sorte que le runtime puisse faire référence à package.json qui se trouve dans le même dossier , et lancez une application. Si vous ouvrez package.json directement, il s'ouvrira dans tout ce qui est associé à .json dans votre système d'exploitation.

Un peu comme un système de raccourcis.

@YurySolovyov Dans ce cas, c'est juste une question de goût si nous définissons ces informations dans package.json ou package.electron. Personnellement, je le garderais séparé simplement parce qu'il me semble plus propre. Peut-être que la propriété des moteurs dans package.json suffirait cependant.

@Tribex c'est également une exigence pour publier une application sur npm - avoir valide package.json

@YurySolovyov Exact . Si nous utilisions package.electron package.json serait toujours présent. .electron ne serait utilisé que pour définir les informations d'exécution ou, dans le cas de votre suggestion, serait simplement un marqueur.

Fondamentalement, le package.electron ne serait là qu'en tant que _marqueur_ lançable, donc le package.json serait toujours présent avec ses propres données, mais c'est pourquoi un fichier séparé serait nécessaire : _double clic ouvre l'application _. J'aimerais toujours pouvoir renommer le package.electron en my-app.electron ou my-app.electron .

@sapioit bien sûr, c'est tout l'intérêt d'avoir un fichier .electron , vous pouvez le nommer comme vous voulez, tant qu'il a l'extension .electron .

Il ne me semble toujours pas très propre que le gestionnaire d'exécution doive regarder *.electron, puis package.json pour déterminer quelle version d'électron exécuter, qui lit ensuite à nouveau package.json.

@Tribex pourquoi pensez-vous que package.json serait lu deux fois ?

• Si nous mettons les informations d'exécution dans le fichier .electron , l'exécution lancera l'application en utilisant package.json en supposant que tout est correct et rapide si ce n'est pas le cas.
• Si nous plaçons le runtime dans package.json directement ou sous la section electron , cela ne nécessiterait également qu'une seule lecture. De cette façon, je ne sais pas quoi mettre dans le fichier .electron (idées ?), ça irait même s'il était vide.

@tribex Le .electron pourrait pointer vers le package.json , juste au cas où, pour certaines raisons, le package.json serait renommé. De cette façon, vous pourriez avoir un package.json pour NPM et un autre package.json (peut-être electron.json ) pour l'Electron. Pourquoi? Vous souhaitez peut-être que votre application ait le package.json pour savoir ce qu'il faut importer avec le gestionnaire de packages, mais une fois importé, vous souhaitez l'exécuter sans avoir à déplacer ou renommer les fichiers.

_ app.electron _

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

ou

_ myapp.electron _

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

Ou, si nous mettons tout dans package.json , nous pourrions avoir le seul lien .electron vers le .json que nous voulons utiliser pour ouvrir l'application, donc :

_ app.electron _

{
  "package": "package.json"
}

ou

_ myapp.electron _

{
  "package": "electron.json"
}

De plus, vous souhaitez peut-être avoir deux lanceurs dans le même répertoire, un pour le client et un pour le serveur, le client utilisant les fichiers du serveur pour lancer un serveur local avec un seul lecteur. De cette façon, vous n'aurez pas besoin de dupliquer les 99 % des fichiers (en supposant que vous avez un jeu qui utilise plus de 500 Mo de fichiers) et 5-6 fichiers différents, et de les avoir dans deux répertoires séparés, mais n'en avez qu'un supplémentaire fichier pour pouvoir lancer le serveur tout seul. Littéralement, la même chose que d'avoir plusieurs exécutables dans le même répertoire.

package.electron séparé doit être nommé package.electron.json ou quelque chose qui a l'extension .json pour le bien des éditeurs et de l'IDE pour déterminer correctement la syntaxe.

@StreetStrider Je préférerais enseigner aux IDE que .electron est en fait valide .json .
Et cela nous amène également au point dont nous avons discuté avec @sapioit à propos des associations .json . Je ne pense pas qu'un système d'exploitation populaire prenne en charge les associations à double extension. ( .foo.bar )

Vous pouvez ajouter l'extension .json lorsque vous la modifiez. ou faites un clic droit et ouvrez avec un éditeur, mais tout comme Adobe Air, qui, par défaut, ouvre le fichier avec son lanceur, permettant à l'utilisateur d'ouvrir le fichier avec un éditeur, cela ne poserait aucun problème.

@sapioit Juste un point, je suppose que je suis d'accord avec vous pour pointer vers le package.json.

Pour moi, un runtime et un player sont deux choses distinctes. Cela se passe davantage en tant que joueur maintenant. Et il ne semble pas qu'il serait largement utilisé en dehors d'une communauté à tendance technique habituée aux concepts de gestionnaires de paquets.

Le problème est de créer un runtime. Un peu comme JRE et .Net. Pas un joueur.

@baconface Peut-être pourriez-vous élaborer? La distinction que vous faites ici n'est pas claire.

@baconface oui, mais JRE et .Net sont également installables.
Sans JRE, les fichiers .jar sont aussi inutiles que les packages sans le runtime electron .

Idéalement, cet outil serait distribué avec ou comme méthode principale d'installation d'électrons, atténuant idéalement le problème de propagation.

Pour cela, vous n'auriez besoin que d'un petit outil pour créer un exécutable qui lancerait un certain fichier, à savoir le .electron imputé. Aussi simple que cela.

.lept a l'air génial, merci !

Personnellement, je pense qu'il n'est pas nécessaire d'inventer une nouvelle configuration, pkg.engines me semble assez simple ici (cela devrait cependant permettre certaines expressions semver compliquées, comme 1.x || >=2.5.0 || 5.0.0 - 7.2.3 de la documentation de npm , donc pas besoin de { recommended, compatible, etc } -structures comme dans les exemples de @sapioit , je crois). (J'ai cependant ajouté un champ lepton , car scripts.run est généralement invoqué par npm start , et lepton en brise quelque peu la sémantique en ajoutant son propre $VARIABLES .)

Ou, si nous mettons tout dans package.json, nous pourrions avoir le lien .electron uniquement vers le .json que nous voulons utiliser pour ouvrir l'application

Cela ne me semble pas non plus une bonne idée. Si nous avons un package avec plusieurs points d'entrée, nous pourrions toujours les avoir tous dans un seul package.json, comme si nous avions maintenant une carte scripts . Je pense à quelque chose comme ça :

// 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

Ensuite, si vous voulez vraiment cela en tant que fichiers exécutables, sous Linux / macOS, vous pouvez utiliser des scripts shell simples (3 lignes dont #!shebang), et sous Windows... eh bien... ¯_(ツ)_/¯

Tout d'abord, vous voudrez peut-être jeter un œil à cet article, qui offre une meilleure alternative à semver, tout en restant compatible avec à peu près tout ce qui existe : Release.Breaking.Feature.Fix ou pourquoi la version sémantique devrait être remplacée par la version explicite comme dès que possible

Deuxièmement, la question est de savoir comment les différencier réellement. Je veux dire, si server.js accepte déjà l'argument --debug , pourquoi s'embêter avec ça et ne pas permettre aux gens d'avoir leurs propres configurations de fichiers. Peut-être que le serveur nécessite des configurations différentes de celles du client, comme le client travaillant sur 2.2-2.4 et le serveur ne travaillant que sur 1.4-1.9.2.1 ...
En faisant comme vous l'avez suggéré, nous n'en serions que plus limités.

Aussi, qu'en est-il de l'utilisation de plus de variables, pas seulement --debug ? Comment vais-je l'exécuter avec plus de variables comme celle-ci ? Est-ce sécuritaire de le faire? Après tout, si je voulais qu'un seul fichier fasse cela, j'aurais pu le faire même avec des fichiers séparés, mais de cette façon, cela gâche les résultats possibles de l'exécution du fichier .lept avec des paramètres.

Si je voulais exécuter le serveur avec le paramètre de débogage, ne lancerais-je pas simplement le .lept avec l'argument --debug ? Ou je pourrais créer un autre fichier pour lancer ce fichier avec l'argument --debug . N'est-ce pas si simple ?
J'espère que j'ai du sens...

Tout d'abord, vous voudrez peut-être jeter un œil à cet article, qui offre une meilleure alternative à semver

Je pense que c'est une excellente idée! Cependant, je ne pense pas qu'Electron passera à ce schéma de version. Je pense également que même si c'est génial pour les produits destinés aux utilisateurs finaux, nous n'en avons pas vraiment besoin pour les bibliothèques, les moteurs, les runtimes, etc. Idéalement, l'utilisateur ne devrait même pas savoir quelle version d'Electron il utilise (sauf s'il le souhaite).

Peut-être que le serveur nécessite des configurations différentes de celles du client

Cela pourrait être un problème, mais je ne peux pas imaginer un projet qui aurait besoin de plus d'une version d'un runtime.

Si je voulais exécuter le serveur avec le paramètre debug, ne lancerais-je pas simplement le .lept avec l'argument --debug ?

Ouais pourquoi pas:

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

Ce package.json à double configuration est idéal pour les cas où le serveur a) partage beaucoup de base de code avec le client, et b) est destiné à être exécuté par les utilisateurs finaux. Dans d'autres cas, il serait logique de tout séparer en deux repos/packages, chacun avec son propre package.json.

Ce n'est pas pour Electron, mais pour les projets que vous construisez. Electron a probablement son propre système dérivé de la version sémantique pour répondre à leurs besoins, et il est peu probable qu'ils le changent, mais pour Lepton et d'autres projets qui ne sont pas si loin dans _ development hell _, il peut être judicieux d'ignorer complètement la gestion des versions sémantiques.

Si je voulais exécuter le serveur avec le paramètre debug, ne lancerais-je pas simplement le .lept avec l'argument --debug ?

Ouais pourquoi pas:

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

Non, je ne veux pas dire dans la configuration, mais via le lanceur. Donc ça:

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

Mais lancez le .lept avec l'argument --myoption=5 sans toucher aux fichiers (en plus de les ouvrir). Comme je suis à peu près sûr que vous pouvez "_pousser_" l'argument via le lanceur, vous pouvez également supprimer le besoin de --debug , puisque vous le lancerez avec l'argument personnalisé si vous le souhaitez.

Mais sur une chose, je pense que nous pouvons être d'accord : les utilisateurs veulent être sur une version stable pour laquelle ils bénéficient d'un support. C'est pourquoi j'ai fait du " Release " son propre numéro, car il est peu probable que les gens se souviennent de nombreux numéros, mais ils se souviennent généralement du premier.

@sapioit si le champ "Release" est destiné aux utilisateurs finaux, à quoi servent les autres ? Pour l'utilisateur final, cela ne devrait pas avoir d'importance du tout, si une nouvelle version est disponible et qu'elle nécessite une mise à jour de l'exécution (via bump dans package.json), alors l'exécution doit également être mise à jour.

Voici les problèmes :

1. Les utilisateurs veulent savoir pour quelle version ils sont pris en charge .
2. Ils ne veulent pas se souvenir de beaucoup de _nombres inutiles_, donc s'ils choisissent de se souvenir de la version, ils sont plus susceptibles de se souvenir de la version 13 que de la version 1.7 (par exemple).
3. Certaines personnes ne veulent pas mettre à jour jusqu'à ce que certaines choses se produisent, comme le fait qu'un certain nombre de pilotes nVidia ne sont pas mis à jour car depuis l'ajout de la compatibilité Thunderbolt, leur (s) carte (s) graphique (s) est (sont) éjectée (s) au hasard (selon l'utilisateur/cas , soit après le démarrage de l'ordinateur, après avoir ouvert un jeu ou après quelques minutes de jeu). C'est un bon exemple de raison (mais il y en a beaucoup d'autres, comme les publicités de KMPlayer ou locked on mises à jour automatiques ) qui empêchent les utilisateurs d'utiliser la dernière version d'un produit. Cela facilite la consultation du journal des modifications, en en supprimant la complexité.

Ce ne sont là que quelques-unes des raisons... si vous pouviez entrer dans plus de détails, je pourrais aussi entrer dans plus de détails et mieux vous expliquer pourquoi ces choix ont été faits.

@sapioit Les plages de semver comme >= 12.1 ne sont-elles pas suffisamment flexibles pour déclarer le support?
Si une nouvelle version du runtime est disponible et qu'elle correspond à la plage de versions, tous les prochains lancements d'une application doivent utiliser le dernier runtime possible.

Devraient-ils? Mais que se passe-t-il s'ils décident de ne pas le faire, en raison de limitations techniques (comme le truc avec les publicités de KMPlayer et les pilotes nVidia) ?

@sapioit Ensuite, assurez-vous d'avoir correctement indiqué votre plage d'exécution

@sapioit @YurySolovyov Cette discussion est-elle pertinente ici ? Un gestionnaire d'exécution devrait suivre le système de gestion des versions qu'électron utilise. Je crois qu'une discussion sur le système de gestion des versions que l'électron _devrait_ utiliser appartient à un autre numéro.

@Tribex un peu. J'essayais de dire qu'il ne faut pas trop compliquer des choses qui sont déjà fondamentalement résolues. Mais je suis d'accord que le gestionnaire d'exécution devrait faire la chose la plus simple possible à cet égard.

@yurysolovyov Alors pourquoi ne pas simplement autoriser autant de sections dans le numéro de version que le joueur le souhaite ?

@sapioit

Ce n'est pas pour Electron, mais pour les projets que vous construisez.

Lepton n'a pas (encore) de schéma de version attribué et les packages (applications) peuvent utiliser n'importe quel schéma de version de leur choix. Nous devons gérer cela (par exemple, si nous voulons prendre en charge la mise à jour des applications via le Lepton lui-même).

Les runtimes, idéalement, devraient utiliser semver, car ce ne sont pas des produits, mais encore une fois, toute gestion des versions à 3 chiffres est désormais prise en charge (les développeurs doivent toutefois faire attention à la spécification des plages). Si jamais nous avons besoin de prendre en charge plus de 3 nombres (comme avec votre proposition de versionnage explicite), nous aurions besoin d'étendre l'analyseur (pour Python, je suggère de bifurquer k-bx/python-semver ou podhmo/python-semver - l'ancien a été mis à jour plus récemment, tandis que le premier suit plus étroitement l'API node-semver et c'est ce que j'utilise actuellement).

Puis-je simplement dire qu'avoir un gestionnaire de packages d'exécution écrit en python pour un projet nodejs n'est qu'une mauvaise idée.
Ne le faisons pas. Peu importe comment ça s'appelle, lepton, ou quoi que ce soit. Écrivons-le dans node, ou utilisons autre chose. Et ne spammons pas ce problème avec des e-mails inutiles sur la façon dont vous pensez que vous savez mieux que le schéma de version sémantique bien pensé

@championswimmer Il serait intéressant de construire le gestionnaire d'exécution avec une version d'électron fournie avec lui, et une interface utilisateur pour montrer quand d'autres versions sont en cours de téléchargement.

@championswimmer iamale/lepton est une sorte d'implémentation de référence jetable : je l'ai juste mise en place pour tester diverses idées flottant autour de ce fil, rien de plus.

@iamale peut-être devriez-vous l'indiquer dans le fichier readme pour éviter toute confusion alors ?

@YurySolovyov Terminé !

Quant à l'implémentation réelle, nous avons deux options : soit nous utilisons node.js, soit un langage compilé comme C/++ ou Go ; et pour node, nous devrons regrouper node.js avec (ou peut-être simplement l'exécuter sur l'une des instances d'électrons téléchargées ? Nous devrons cependant nous assurer qu'il fonctionne sur _any_ sane version electron).

@iamale Pas vraiment, nous devons juste exécuter une version installée par défaut. Après cela, les mises à jour peuvent le basculer vers une version plus récente sur place.

Je préfère choisir d'utiliser une certaine version, car si besoin, tout peut être mis à jour...

Lepton n'est peut-être plus un si grand nom maintenant qu'il s'agit d'un format d'image .

Alors... comment l'appelle-t-on maintenant ? Hadron ?

Quark ? Si quelqu'un veut prendre le nom "Muon" je peux renommer un de mes projets.

Nommer n'est-il pas la partie la moins importante ici ?
Avons-nous convenu de la sémantique d'installation/mise à jour/d'exécution ?

Pourquoi pas juste electron ...

Op 15 juil. 2016 à 13:22 heeft Joshua Bemenderfer [email protected] et volgende geschreven :

Quark ? Si quelqu'un veut prendre le nom "Muon" je peux renommer un de mes projets.

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

@yurisolovyov Je pense que nous étions d'accord... plus ou moins.
@job-v C'est ce que je suggère depuis le début. Choisissons-en un et respectons-le.

@zcbenz observez -vous ce fil?
Si c'est le cas, ce serait bien d'avoir une vision sur la façon dont cela devrait fonctionner pour obtenir des indications ici.

salut
des mises à jour sur ce runtime d'électrons ?
@zcbenz que pensez-vous de toutes les discussions sur :

• sélection de la version électronique
• installer la version appropriée
• préparez-le à fonctionner sous win, linux, mac
• quel outil utiliser pour compiler avec (python, node, go, c++) ?
  @YurySolovyov @sapioit merci pour vos idées géniales
  @iamale est votre travail de solution pour les destros basés sur Debian 'ubuntu ...'

@alnour-altegani
Oui, cela fonctionnerait pour toutes les distributions basées sur dpkg car nous ne dépendons pas de packages extérieurs. Les packages RPM peuvent être générés de la même manière, pourquoi pas ?

Je pense à démarrer un référentiel central pour toutes les choses Electron, donc vous pourriez exécuter:

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 Je pense que faire de l'électron en tant que paquet deb et l'utiliser comme dépendance dans l'application à installer manuellement ou à partir du référentiel central pour de nombreux paquets deb de la version électronique.
puis utilisez ce package après l'installation pour exécuter l'application utilisateur

Si quelqu'un commence à travailler sur quelque chose pour cela, peut-être un lien vers celui-ci ici...

@sapioit J'ai commencé à travailler sur une solution Linux (APT/RPM). Un service simple sur lequel vous téléchargez .asar et qui est converti en packages et ajouté aux référentiels. Devrait également être extensible à Windows et macOS, mais aucune promesse à ce sujet pour le moment.

@iamale Cool ! Faites-moi savoir quand vous le faites fonctionner sur Windows.

Qu'en est-il de la création d'un environnement d'exécution Flatpak pour Linux ? De cette façon, le runtime peut être partagé entre plusieurs applications et vous bénéficiez également d'un sandboxing.

Avec Flatpak supprimant sa dépendance à systemd , il deviendra probablement universel sous Linux pour l'empaquetage en amont.

le runtime peut être partagé entre plusieurs applications

Je pensais qu'avec Flatpak ce ne serait pas possible ?..

@iamale Flatpak est conçu pour partager les runtimes - les développeurs d'applications choisissent un runtime, installent le SDK pour ce runtime, puis créent une application avec flatpak-builder ou similaire. Ensuite, lorsque l'utilisateur installe l'application, Flatpak installe le runtime associé.

@moosingin3space Merci pour l'explication ! Cela vaut vraiment la peine d'être considéré alors.

L'autre chose que j'aime à propos de Flatpak est qu'il a été conçu autour du cas d'utilisation où un utilisateur ajoute un référentiel exécuté par le développeur d'exécution et le développeur d'application (de manière transparente) et cela rend les mises à jour automatiques.

Les seules choses que je peux voir comme des problèmes sont liées à la sécurité - il faut modifier les bibliothèques système pour utiliser l'interface "portails" dans Flatpak pour permettre une sortie en toute sécurité du bac à sable.

Il semble y avoir du travail sur Flatpak ici : https://github.com/endlessm/electron-installer-flatpak

En passant, Flatpak est basé sur le projet OSTree , qui effectue l'adressage de contenu pour les arborescences du système de fichiers. Cela signifie que les fichiers avec des sommes de contrôle identiques sont automatiquement dédupliqués sur le disque et que les mises à jour sont effectuées à l'aide de deltas statiques. Cela signifie que non seulement Electron pourrait fournir un runtime de partage qui peut être mis à jour et partagé indépendamment entre les applications, mais aussi que les applications construites sur des fichiers identiques les partageraient automatiquement sur le disque, et qu'une fois qu'une application et/ou un runtime sont installés, les mises à jour ne nécessiterait pas un téléchargement complet.

Pardonnez-moi si c'est un peu naïf, je me demande si la possibilité de créer un environnement de bureau comme une progression logique naturelle de l'environnement d'exécution a été envisagée. L'idée étant qu'il existe une application de lancement que l'électron charge au démarrage (au lieu de dire, l'atome) avec la possibilité de lancer d'autres applications électroniques (compte tenu de la grande bibliothèque croissante) en créant de nouvelles instances du moteur de rendu ou peut-être même en le réutilisant et avoir les applications s'ouvrent dans un nouvel onglet.

Chrome, comme dans le système d'exploitation, à ma connaissance, semble être exactement cela (mais se limitant aux applications Web). Avoir des applications de bureau avec un accès fs complet via nodejs (par opposition aux limitations des chromeAPI) avec electron comme environnement d'exécution au-dessus de Linux (ou même remplacer ou au moins augmenter au début explorer.exe dans Windows) serait très excitant à mon humble avis. Je pense que c'est une solution plus propre que ChromeOS qui charge ce qui est en fait un runtime, puis un moteur de navigateur, puis héberge une application - ici, on chargera les applications directement dans le runtime et le navigateur lui-même ne sera qu'une autre application (et il y en a tellement de nombreux projets innovants de navigateurs d'électrons dans la nature).

Encore une fois, je me demande si cela a été envisagé ou s'il existe déjà un projet qui le fait. Sinon, peut-être qu'une fée peut mettre un mot dans les oreilles de la direction de Github pour avoir pris les devants ????

PS: Une chose que je ne suggère pas ici est de porter OS.js (qui est un joli petit projet en soi) vers electron mais de créer un environnement pour les applications electron (bien que je ne serais pas opposé à la réutilisation du code depuis OS.js).
PPS : Je créerai un problème distinct si celui-ci est considéré comme suffisamment valable ou s'il s'agit d'une distraction par rapport au problème d'un environnement d'exécution.

Je pense qu'un environnement d'exécution intégré améliorerait considérablement les applications Electron. Je pense que les emballer devrait simplement compresser les fichiers et renommer l'extension en asar , mais cette archive devrait avoir deux dossiers, un appelé asar , avec le contenu du dossier d'exécution par défaut, et un appelé enviroment avec des fichiers qui doivent écraser la configuration par défaut.

Par exemple, l'exécution d'une nouvelle application copierait la version requise d'Electron dans un dossier temporaire et déplacerait le runtime (contenu du dossier asar ) dans l'emplacement des fichiers par défaut, tandis que le dossier facultatif enviroment (avec 3 sous-dossiers, windows , linux , macosx ) devrait contenir des fichiers qui seraient collés sur le dossier par défaut, en écrasant son contenu.

De cette façon, nous n'avons besoin que d'une application ou de quelque chose pour évaluer l'extension .asar d'une application, et faire en sorte que cette application accède au dossier avec les versions téléchargées d'Electron (archivées), les copie (les extrait) dans un dossier temporaire , et utilisez le contenu de .asar pour modifier ce qui est nécessaire, puis exécutez l'instance Electron à partir de ce dossier temporaire et attendez qu'il meure afin de forcer la suppression du dossier temporaire. Pour commencer, même obtenir que la configuration par défaut fonctionne avec une archive avec une extension personnalisée sur tous les systèmes d'exploitation pris en charge représenterait des pas de géant plus que ce que nous avons déjà. Après cela, nous pouvons nous soucier d'avoir un troisième dossier, config , où conserver les paramètres de configuration actuels, et peut-être un dossier _config à l'intérieur, pour les paramètres de configuration par défaut (si nous en avons besoin ).

Les applications packagées Chrome étant bientôt supprimées, les utilisateurs vont rechercher des alternatives. Un environnement d'exécution serait idéal pour les projets mineurs qui n'auront pas toujours de versions/versions disponibles. Étant donné que les applications sont créées avec la technologie Web, tout comme les applications Chrome, il serait utile pour un utilisateur d'exécuter simplement l'application à partir de la source. Je ne peux pas justifier le portage d'innombrables projets mineurs sur Electron si la seule façon pour un utilisateur de les exécuter est de télécharger une grande version binaire pour chaque script ou application individuel, et les utilisateurs ne peuvent pas profiter de l'exécution du dernier commit sans le construire ou télécharger Electron's IDE eux-mêmes.

Salut à tous, même si je ne suis pas dans le monde centré sur le JS, j'ai récemment eu une idée assez similaire à _Electron_ (que je connaissais, mais que je n'utilisais pas pour le développement) mais avec un public plus large ; pour le dire d'une manière très simple : _limitez simplement les technologies Web à l'interface graphique et fournissez des API._

Continuez donc avec une bibliothèque / un runtime partagé avec version sémantique (construit au-dessus de _Blink_, _Skia_, etc.; peut-être en - "moderne" - _C++_) et laissez les développeurs choisir le langage en utilisant des liaisons…
par exemple, vous voulez _JS_, utilisez _Node.JS_ ; vous voulez _C++_, pas de problème ; vous voulez _Python_, avec le _CPython_ standard devrait être possible ; rien d'autre ? peut-être que _SWIG_ peut vous aider. Dans (presque) tous les cas, nous gagnons.

Une fois que nous avons la bibliothèque / l'environnement d'exécution partagé (dépendant du système d'exploitation), vous résolvez le problème principal et pouvez élaborer la manière dont vous pensez qu'il est préférable de fournir le reste (autre que de révolutionner/moderniser l'approche de programmation graphique pour le reste d'entre nous ; un grand pas en avant !).

Donc, le point de départ devrait être le "split" (devrait même avoir un nom lié à la physique, étant donné que vous semblez vraiment vous en soucier) du projet _Electron_… :)

On n'arrive même pas à faire un addon à Electron, mais je pense que ça n'aura pas autant de succès, à moins de beaucoup de publicité.

@dezzeus Il y a eu un effort sur ces lignes avant qui s'est effondré. Jetez un œil au moteur d'exécution destiné à héberger le navigateur de violation .

J'ai lu deux fois ce fil long et fascinant, car j'aimerais voir plus d'élan dans cette direction. Voici la dernière déclaration de @zcbenz , je pense qu'elle est toujours pertinente :

Il n'y a aucun obstacle technique à la mise en œuvre de cela, le tout peut simplement être une application Electron elle-même. Mais le problème est que ce n'est pas facile à mettre en œuvre non plus, en tenant compte de tous les détails, je pense que _cela nécessite une petite équipe qui travaille à plein temps dessus_, je ne suis pas sûr que cela se produira un jour.

(Soulignement ajouté) - Comment j'interprète cela, si jamais la solution doit être construite, cela dépendra des efforts de la communauté et/ou des besoins commerciaux de GitHub et d'autres organisations qui y sont parties prenantes.

Un aperçu concis de @yan-foto ressemble à un plan d'approche sensé, avec des objectifs/exigences clairs. Il existe une implémentation/prototype de référence appelé lepton par @iamale , proposant un "gestionnaire de version d'exécution universel" ciblant Electron. Un commentaire de @jorangreef était intrigant, car il décrit "une application en production avec un mécanisme de mise à jour automatique semver", avec mise à jour différentielle, déduplication (je ne sais pas si ces deux éléments sont identiques) et compression. Bon nombre des fonctionnalités qu'il a décrites semblaient parfaites pour être adaptées/adoptées.

Ce sont des étapes définitives d'exploration et de progrès, et cela me donne l'espoir que des solutions générales dignes de production naîtront de ce processus.

C'est agréable de voir qu'il y a encore des gens qui ont foi en l'humanité.

La seule chose qui empêche cela de devenir un produit est le manque d'opportunités commerciales immédiates ouvertes par la fabrication de ce produit (concept).

@eliot-akira oui, c'est ça. Le code que j'ai écrit effectue une déduplication basée sur le contenu par fichier (morceaux de taille variable) dans un fichier pour minimiser les téléchargements lorsque seuls quelques octets dans un fichier changent. Il met également à jour uniquement les fichiers qui changent entre les versions et les mises à jour de l'application dans son ensemble sont atomiques face à toute erreur. Soit la nouvelle version sera lancée, soit l'ancienne version restera en place.

Je voudrais ouvrir le code, et il y a certaines choses que j'aurais encore besoin de coder pour l'idée globale. Ce serait formidable si plusieurs applications Electron pouvaient partager un seul processus de supervision de mise à jour automatique (avec un cache immuable partagé local pour la déduplication sur plusieurs applications Electron indépendantes).

L'objectif de toute cette approche serait de minimiser la bande passante de téléchargement globale requise pour installer et mettre à jour les applications Electron, tout en gardant les applications Electron complètement isolées les unes des autres (plusieurs applications auraient leurs propres binaires Electron). Un non-objectif serait de minimiser l'encombrement du disque.

La première installation de l'application Electron devrait être téléchargée dans son intégralité, mais les installations ultérieures de l'application Electron bénéficieraient du cache immuable partagé local.

Puisqu'il s'agit d'une mise à jour automatique, je dois apporter le problème de version et le fait que plusieurs systèmes de version semblent utiliser différents nombres de chiffres pour la version. Pour ma part, j'utilise Explicit Versioning .

Nous avons deux types de choses qui doivent être mises à jour ici :

• Electron lui-même, qui utilise Electron Versioning et
• Les applications, pour lesquelles nous n'avons pas vraiment besoin de nous soucier de SemVer ou de quoi que ce soit, car elles n'ont généralement pas d'API (à moins qu'elles n'utilisent peut-être une sorte de système complémentaire).

Bien que si nous avons besoin de prendre en charge plusieurs systèmes de gestion des versions, nous pourrions peut-être avoir un paramètre dans package.json , comme "breakingVersionComponents": 1 pour semver et 2 pour la version explicite ou la version électronique ?

(Une autre option serait d'ajouter un autre séparateur dans la version, comme 1.3:3.7 qui séparerait les parties cassantes et non cassantes. Semver devient alors x:y.z et Electron Versioning x.y:z . casser tous les outils là-bas, cependant, je crois.)

@jorangreef Si chaque application a toujours son propre binaire Electron, cela ne résoudrait pas le problème d'utilisation excessive de la RAM lors de l'ouverture de plusieurs applications Electron.

J'ai remarqué un ancien commentaire de @joshuawarner32 , que j'avais oublié. Il mentionne un exemple déjà fonctionnel, pas encore une solution à usage général, mais le résumé est :

- 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

Parallèlement à l'exemple de @jorangreef (merci pour l'explication supplémentaire - édition : oh, je n'avais pas réalisé que chaque application avait son propre binaire Electron, qui est un modèle différent de ce que je pensais), je vois que les gens construisent déjà leur propres solutions spécifiques au problème d'un environnement d'exécution partagé - qui fournissent également des fonctionnalités d' un lanceur/gestionnaire d'application quelconque. Ce serait formidable de voir une certaine convergence, de répartir certaines de ces fonctionnalités mentionnées dans des modules à usage général.

Je me demande s'il existe des modules existants, non spécifiques à Electron, qui pourraient être exploités, comme le mécanisme de téléchargement : serveur d'exécution, gestion des versions, mises à jour différentielles. Cela semble un peu intimidant de tout construire à partir de zéro, si d'autres ont déjà "résolu" certains de ces domaines. @iamale , merci pour ton travail sur Lepton , à mes yeux c'est une implémentation concrète dans le sens d'une solution.

Une autre idée : publiez simplement des applications dans npm et créez un wrapper npm spécial qui peut les installer et les exécuter. Il serait alors très facile à déployer et probablement facile à utiliser (en fonction de la qualité de l'emballage) également. Qu'en pensez-vous les gars ?

Pour les projets oss, nous pourrions utiliser npm comme hébergement, pour les sources fermées, nous devons pouvoir pointer le gestionnaire de packages vers le fichier .asar à télécharger, et peut-être quelques métadonnées supplémentaires. La question est de savoir à quoi ressemblera (et s'appellera) ce genre de manager

De plus, je me demande si nous avons vraiment besoin d'une commande distincte pour installer des applications, peut-être juste
electron install atom suffirait ?

Je viens de voir ça sur Node Weekly :

Electron est une alternative poids plume expérimentale au populaire et puissant Electron. Il implémente une infime partie des API disponibles dans Electron, mais la taille de l'application de sortie est beaucoup plus petite.

https://medium.com/@pauli/put-your-electron-app-on-a-diet-with-electrino-c7ffdf1d6297

https://github.com/pojala/electrino

@YurySolovyov Les projets source fermés ne devraient pas avoir de problème à être publiés dans npm également - il y en a déjà quelques-uns Node.js, c'est-à-dire enclose . (Techniquement, ce n'est pas dans npm, juste un chargeur, mais de toute façon, je ne vois pas comment le chargement latéral de .asar aiderait car ils peuvent toujours être décompressés.)

J'essayais juste de penser comment pouvons-nous réutiliser autant que possible l'écosystème existant.

Pas sûr qu'on veuille...

@jorangreef Si chaque application a toujours son propre binaire Electron, cela ne résoudrait pas le problème d'utilisation excessive de la RAM lors de l'ouverture de plusieurs applications Electron.

@Jop-V Non, ce ne serait pas le cas. Je ne veux pas confondre les choses et finir avec un monstre. L'idée est d'avoir un excellent programme d'installation/mise à jour automatique qui résout la plupart des problèmes dans le commentaire qui a ouvert ce problème : https://github.com/electron/electron/issues/673#issue -44580957

Le problème n'est pas tant d'avoir plusieurs binaires sur le disque, mais l'impact du réseau sur un utilisateur qui doit télécharger et mettre à jour automatiquement plusieurs copies du même binaire.

Résoudre l'utilisation de la mémoire vaut vraiment la peine d'être fait. Je pense qu'il existe plusieurs façons de procéder, mais elles n'ont pas nécessairement besoin d'être associées à un programme d'installation/de mise à jour automatique de déduplication.

Si l'encombrement du disque est également un problème, cela peut être résolu via des liens physiques sur les systèmes qui le prennent en charge, bien que cela commencerait à enfreindre l'idée d'isolement entre les applications (par exemple, si une application décide d'écrire sur un lien physique partagé avec autre chose).

Alternativement, au moins sur macOS à moyen terme, APFS copiera les fichiers par référence, avec une déduplication transparente sous le capot, minimisant l'encombrement du disque. Ce serait mieux que les liens physiques car cela maintiendrait l'isolation intacte (copie sur écriture).

@jorangreef Quel est l'intérêt d'utiliser des binaires Electron séparés pour les applications ? De quel type d'isolement parles-tu ? Désolé si c'est une question stupide, mais je ne comprends pas.

@iamale Certaines applications peuvent cibler différentes versions officielles d'Electron ou peuvent distribuer un Electron pré-construit compilé à partir de sources modifiées. Cette approche fonctionnerait avec eux tous. Même avec des différences majeures dans les binaires (par opposition au JS et aux changements d'actifs), la déduplication éliminerait 70 % ou plus des exigences de téléchargement, de sorte que les applications ciblant différents binaires en bénéficieraient toujours.

Avec cette approche, il est même possible d'expédier n'importe quel type de package (tout ensemble de fichiers et de répertoires défini par un manifeste JSON), pas nécessairement uniquement les applications Electron. Il peut également s'agir d'une application Python. Il est indépendant de tout choix que le développeur souhaite faire en ce qui concerne la structure ou l'empaquetage de son application (fichiers vs asar, etc.).

L'idée principale est que l'écosystème bénéficie de très petits deltas d'installation/mise à jour, car de plus en plus d'applications utilisent le même programme d'installation/mise à jour automatique. De nos jours, chaque application exécute sa propre mise à jour automatique de supervision et c'est inutile.

@jorangreef Merci ! Je suppose que c'est un peu comme les référentiels APT/RPM classiques, juste plus "intelligents" (pas besoin de déclarer vos dépendances ou quoi que ce soit).

La question est de savoir à quoi ressemblera (et s'appellera) ce genre de manager

Qu'en est-il de Minifitron (électron minifié) ?

Je pense que le fichier d'archive (c'est-à-dire .asar ) doit contenir le contenu du dossier où se trouve le binaire d'électron, afin que nous puissions ajouter ou remplacer les fichiers qui s'écartent de la norme. Nous aurons chaque version dans un dossier ou une archive et la copierons dans un nouveau dossier temporaire pour le temps de son exécution.

Et il devrait y avoir une option pour installer ou minifier les applications, l'installation les laisserait comme une nouvelle instance d'électron, tandis que la minification utiliserait md5 pour supprimer les fichiers qui n'ont pas été modifiés par le désarchivage du .asar (ou ce que nous utiliserions) et archivez-le et remplacez le fichier d'origine, en tant qu'état mis à jour de l'application que nous avons utilisée.

Juste pour ajouter une autre idée : et si chaque application Electron contenait ses propres copies d'environnements d'exécution, mais au lancement, elle pourrait vérifier s'il existe une instance d'Electron déjà en cours d'exécution (et sa version) - si elle est compatible (dans la plage semver , etc.), l'application pourrait communiquer avec lui et utiliser cette même instance ; si elle n'est pas compatible, l'application peut démarrer sa propre instance d'Electron. Cela semblerait résoudre le problème de la réduction de l'empreinte mémoire.

(Là encore, au moment où l'application est lancée, je suppose qu'il y aura déjà plusieurs instances de l'exécution de toute façon... donc ce n'est peut-être pas logique..)

@eliot-akira a eu une idée très similaire en lisant ce fil.

(Là encore, au moment où l'application est lancée, je suppose qu'il y aura déjà plusieurs instances de l'exécution de toute façon... donc ce n'est peut-être pas logique..)

Eh bien, il pourrait charger juste assez pour vérifier cela, et après avoir constaté qu'il n'y a pas de "compagnon électronique" disponible avec lequel partager le temps d'exécution, chargez le reste.

Cela créerait cependant beaucoup de problèmes de sécurité. Une application malveillante pourrait proposer une version modifiée du runtime à d'autres et accéder à leurs données. Peut-être pourrait-il utiliser un segment de mémoire partagée, le rendre en lecture seule, et les applications "utilisateurs" (qui utilisent le temps d'exécution d'une application précédemment lancée) pourraient effectuer une somme de contrôle du temps d'exécution, mais les développer pour tous les systèmes d'exploitation ciblés pourrait être un cauchemar ( Je ne sais même pas si cela existe dans Windows ; je suppose que c'est le cas).

Ne serait-ce que par curiosité, est-ce absurde ? Serait-ce autant, ou peut-être beaucoup plus de travail qu'un environnement d'exécution partagé séparé ? Cela crée-t-il d'autres problèmes supplémentaires ?

AJOUTÉ PLUS TARD : C'est peut-être loin, mais il existe des technologies pour dédupliquer des pages identiques sur la RAM ; ils sont principalement utilisés dans les environnements de virtualisation et les hyperviseurs. C'est la première chose à laquelle j'ai pensé et couru pour vérifier si les systèmes d'exploitation d'aujourd'hui l'utilisent, et alors il y aurait peut-être un moyen de régler l'électron de manière à ce que cette fonctionnalité puisse être exploitée, mais apparemment pas.

@jorangreef Si un développeur modifie le binaire Electron, ne devrait-il pas simplement créer une demande d'extraction ?

@Jop-V Ils le peuvent, mais ils peuvent également entretenir leur propre fourche. Ils peuvent même ne pas publier les sources s'ils ne le souhaitent pas - la licence MIT ne leur impose aucune obligation.

@jkurei Pour approfondir l'idée, j'imagine plusieurs façons qui pourraient fonctionner :

1) Un mince wrapper natif autour d'Electron ou de l'application elle-même, ce serait le "lanceur". Il recherche une instance d'Electron déjà en cours d'exécution et sa version : si elle est compatible, transmet le reste du processus de lancement à cette instance et quitte ; sinon, continuez à lancer sa propre instance d'Electron.

2) Une bibliothèque JavaScript que les applications elles-mêmes pourraient importer dans le processus principal, en tant que lanceur. Il pourrait implémenter un protocole similaire à ci-dessus : diffuser l'existence d'une instance Electron, et un moyen pour d'autres applications (utilisant la même bibliothèque) de la trouver et de communiquer avec elle - peut-être via un port réseau... ?

@eliot-akira Je pense, soit dit en passant, qu'il existe déjà une sorte de "protocole" primitif dont vous parlez; c'est cette chose derrière app.makeSingleInstance qui détecte en quelque sorte les processus Electron déjà en cours d'exécution et s'ils sont la même application ou non (probablement en obtenant le chemin exécutable complet).

@iamale Je vois, la méthode utilise la classe native ProcessSingleton de Chromium, pour enregistrer le répertoire de l'application actuelle (en tant qu'identifiant unique?). Oui, j'imaginais quelque chose comme ça, à initialiser avant app.on('ready') . Ainsi, au lieu de simplement vérifier l'instance existante de cette application particulière, il pourrait vérifier n'importe quelle instance d'Electron - puis "transmettre le processus de lancement" si compatible.

Pour un autre angle, j'ai trouvé un module appelé node-ipc qui peut communiquer entre des processus Node.js distincts. Peut-être que cela pourrait être utilisé pour gérer le processus de lancement uniquement sur la couche JS.

Voici un exemple de base de partage d'une seule instance Electron entre plusieurs applications, en utilisant node-ipc pour la communication inter-processus : https://github.com/eliot-akira/singletron-example.

Le hub IPC est son propre module , une mince enveloppe autour node-ipc . Son initialisation est dans le processus principal, main.js en bas .

Au démarrage, l'application tentera d'abord de se connecter à une instance Electron existante. S'il n'y en a pas, il démarrera un "serveur" qui écoute les requêtes inter-processus. Toutes les instances suivantes de l'application se connecteront à la première instance, recevront sa "config" (versions de Chrome, Node, Electron) et pourront échanger des messages, par exemple, pour demander une nouvelle fenêtre pour elle-même.

C'est une implémentation naïve pour commencer, mais ce que j'aime dans l'approche, c'est qu'il appartient à l'application de gérer la manière dont le serveur/les clients doivent négocier : vérifier la compatibilité, ouvrir de nouvelles fenêtres, passer d'autres configurations, etc.

@eliot-akira Je pense que spécifier un ID de serveur par défaut est une _vraiment-vraiment-mauvaise_ idée à ce stade : si quelqu'un commence à l'utiliser à ses propres fins, il modifiera probablement votre exemple de code pour ses propres besoins et rompra le protocole ( brisant ainsi d'autres applications qui en dépendent).

A part ça, ça a l'air bien et propre, merci!

Re : problèmes de sécurité : les applications Electron fonctionnent déjà avec les privilèges de l'utilisateur, et si nous les plaçons dans une arborescence de processus, elles auront en effet (ou pourront obtenir) un accès à d'autres instances Electron. Cependant, je pense que si nous voulons atténuer cela, le fait que tout le monde soit en mesure de fournir une instance d'Electron corrigée n'aidera certainement pas.

@iamale Merci pour les commentaires. J'ai exposé l'option de définir l'ID du serveur, au cas où certaines applications voudraient implémenter leur propre protocole, plutôt qu'un commun pour toutes les applications Electron. En fait, il n'y a pas encore de protocole commun de ce type - donc, à ce stade, ce n'est pas pratique à cette fin, pour que des applications inconnues se connectent et transmettent le processus de lancement. C'était censé être une preuve de concept, donc je mettrai à jour la doc pour le mentionner. Je vais continuer à explorer comment le rendre plus pratique.

Je pense qu'il serait utile pour les nouveaux arrivants d'avoir à nouveau une sorte de résumé, semblable à celui que quelqu'un a fait il y a six mois.

De plus, que fait l'utilisateur final ?

Si j'étais l'utilisateur final (et en partie je suis ofc), je voudrais un seul package .exe/.app/.deb qui fonctionne un peu comme le programme d'installation de portableapps.net. Ce fichier exe doit être petit et télécharger automatiquement la dernière version en amont du logiciel avec le Runtime s'il n'a pas été installé. Dans un processus de configuration simple, je devrais pouvoir définir manuellement un "emplacement d'exécution" (en utilisant la case à cocher des options avancées) avec des cases à cocher pour créer des liens système (Bureau, menu Démarrer, etc.).

Lorsque je télécharge le prochain logiciel, le runtime précédent (quel qu'il soit, idc) doit être réutilisé si possible.

En tant que développeur, je voudrais pouvoir créer un tel package téléchargeable en (au mieux) un seul clic. Ce clic devrait télécharger mon code dans un référentiel (similaire au play/web/app store) et créer un package .exe/.app/.deb pour moi que je peux partager avec le monde.

Je ne suis pas encore impliqué dans Electron, car je suis en train de créer un petit installateur de mod utilisant Electron et Electron-Edge pour C#.

Je suis peut-être naïf, mais autant que je sache, la seule "vraie" raison pour laquelle les choses ne sont pas compatibles avec les versions + -0.1 est que les fichiers .node doivent être reconstruits pour chaque version d'Electron. Ces fichiers .node ne pourraient-ils pas être créés lors de l'installation à l'aide d'une sorte de solution cloud ?

De plus, serait-il vraiment si important de créer un gros Electron LTS tous les six mois environ? Je doute que les développeurs utilisent réellement toutes les fonctionnalités de pointe de chaque nouvelle version d'Electron, donc si nous les forçons (en quelque sorte) à rester avec une version plus longtemps, cela rendrait vraiment les choses beaucoup plus faciles.

Imo, le seul problème est de ne pas avoir de version LTS d'Electron sur laquelle tout le monde peut compter.

Avec cette version, créer la mise à jour automatique, la déduplication, la gestion des versions et toutes ces autres choses devrait être un jeu d'enfant.

La solution d'installation que j'ai proposée a également l'avantage supplémentaire que l'utilisateur ne voit pas vraiment le dossier du logiciel, nous n'avons donc pas besoin de le conditionner en tant que .whatever et de lui dire de le déplacer dans un endroit sûr. De plus, plusieurs "sous-exécutables" peuvent être ajoutés lors de l'installation (par exemple pour les jeux multijoueurs, plusieurs "profils", etc.). Ces exécutables devraient simplement s'appeler somelaunchername.electron, mais au format Json avec des informations sur la façon de lancer le logiciel (comme quel index.html charger et des trucs comme ça). node_modules doit être partagé entre les exécutables (à moins que le développeur NEEDS d'utiliser différentes versions d'un module pour chaque exécutable). Cela pourrait être réalisé en ayant trois dossiers node_modules. Un pour chaque exécutable et un pour les deux. Dans le package.json, il n'y aurait que des informations générales. Chaque fichier .electron doit (imo) pouvoir écraser les valeurs du package.json.

Ces fichiers .electron pourraient ensuite être ajoutés au menu Démarrer et à d'autres emplacements en utilisant "runtime --appname" ou un protocole personnalisé comme steam. Je ne sais pas lequel est le meilleur, mais celui à vapeur m'a énervé plusieurs fois dans le passé.

Maintenant, si le développeur veut vraiment expédier un runtime modifié, il peut toujours le conditionner comme c'est actuellement le cas.

De conclure:
À mon avis, la prochaine étape consiste à créer une version lts stable et à embarquer les développeurs en leur fournissant une solution de packaging simple. Le processus d'installation pourrait être amélioré ultérieurement, actuellement il suffit de télécharger un runtime et un lanceur pour ces fichiers .electron.

Qu'en pensez-vous?

@CiriousJoker electron-builder peut créer une application portable et un programme d'installation Web. Autant que je sache, sur Windows, la DLL partagée est une solution. La DLL partagée prend également en charge le comptage de références, pour supprimer automatiquement le temps d'exécution des électrons inutilisés. Actuellement, l'exécution d'électrons sur Windows dans le seul gros exe (sauf node.dll). S'il peut être divisé en dll, la solution côté générateur d'électrons est assez facile à mettre en œuvre. Cela permettra également d'économiser de la mémoire, pas seulement de l'espace disque.

@zcbenz @paulcbetts Avez-vous envisagé d'utiliser une DLL partagée ? Est-il possible de réduire la taille de l'exe et de déplacer tout le code électronique dans la dll (donc, ne conservez qu'un minimum de code dans l'exe) ? C'est cool que depuis l'électron 1.7.5, le runtime C partagé soit supprimé de node.dll et exe. Maintenant, 30 Mo de code sont déjà dans les fichiers DLL (mais exe est toujours gros - 80 Mo), donc je peux commencer à l'expérimenter.

@develar imo, le vrai problème n'est pas de savoir comment nous pouvons partager des dll, mais plutôt comment nous pouvons obtenir une version lts d'électron

Chromium propose-t-il même des correctifs de sécurité pour les anciennes versions ? J'ai le fort sentiment que leur politique est de "mettre à niveau vers la dernière version pour être sécurisé". Sans mises à jour de sécurité de Chromium, un LTS d'Electron semble bien loin.

@sedwards2009 Mais y a-t-il vraiment autant de menaces ? Bien sûr, je suis peut-être naïf ici, mais nous ne protégeons pas les utilisateurs de l'Internet ouvert, mais des applications (principalement) locales. L'exécution de n'importe quel fichier .exe est 10 000 fois plus dangereuse et l'écriture de virus .exe est également 10 000 fois plus facile lorsque même le programme d'installation de mon application électronique légitime a été qualifié de virus par AVG.

Donc pour moi, "renouveler" cette sécurité tous les 6 mois environ est suffisant. De plus, c'est beaucoup moins sûr de laisser chaque développeur utiliser sa propre version packagée de chrome, ils pourraient faire bien plus de mal avec cela de toute façon que nous ne pouvons pas empêcher (avec un runtime partagé ou autre)

Oui, la sécurité se termine là où l'application obtient un accès brut au fs et au réseau.
Soit vous faites confiance au fournisseur de l'application, soit vous restez à l'écart. <- c'est pour les applications à source fermée.
Pour les OSS, c'est mieux, la plupart d'entre eux au moins n'ont pas de mauvaises intentions, mais peuvent contenir des bugs.

D'accord, alors est-il facile d'obtenir une version lts ? Ne pourrions-nous pas simplement choisir la version actuelle et la déclarer une version lts ?

Le plus gros problème surviendra probablement plus tard, lorsque nous essaierons de convaincre les développeurs de créer leurs applications pour cette version spécifique, mais c'est de toute façon la dernière étape. Pour créer un environnement d'exécution partagé, nous devons d'abord choisir un environnement d'exécution

Je dirais que cela devrait être la décision du développeur - pour déterminer sur quelles versions d'exécution l'application devrait fonctionner.
Un peu comme le champ moteurs npm .
Le travail de Runtime ici est de récupérer la dll nécessaire ou autre et de permettre à l'application de s'exécuter.

Mais si nous leur permettons de choisir l'un des dizaines d'environnements d'exécution presque identiques qui ne sont pas compatibles, nous passerions à côté de l'essentiel, n'est-ce pas ? Nous essayons d'éviter d'avoir plusieurs runtimes, pas seulement de les dédupliquer. Comme quelqu'un l'a mentionné quelque part au début, la déduplication des runtimes n'a pas beaucoup de sens lorsqu'il y a 1 chance sur 20 que le même runtime soit réutilisé sur le même système.

Ou voulez-vous dire que nous partageons la majeure partie du temps d'exécution et que nous changeons simplement les différentes parties selon les besoins ? Cela aurait du sens, mais j'imagine que c'est difficile à mettre en œuvre

Je ne vois pas comment le temps d'exécution peut être partagé, les principaux consommateurs sont Chromium et Node, qui sont étroitement intégrés et je doute qu'ils puissent fonctionner avec plus d'une version l'un de l'autre.

Je pense que node avait quelque chose comme ça:

• certains développeurs voulaient la dernière v8 et étaient d'accord pour tolérer la casse
• les grandes entreprises voulaient de la stabilité et un soutien à long terme.

Je ne suis pas sûr que l'équipe d'électrons dispose de suffisamment de ressources pour prendre en charge les deux, mais je me trompe peut-être.
Quoi qu'il en soit, cela n'entre pas en conflit avec les plages de versions, il suffit d'indiquer quelles versions sont "LTS"

Eh bien, si chaque application électronique utilise le même environnement d'exécution et n'est livrée qu'avec le package .asar spécialement conçu pour cet environnement d'exécution, les choses fonctionneraient, n'est-ce pas ?

Oui, mais vous voulez de temps en temps de nouveaux Chrome et Node, n'est-ce pas ?

Oui, mais je pourrais vivre avec le même nœud/chrome pendant 6 mois np. Node a de toute façon une version LTS et le chrome ne change pas beaucoup par rapport à ce que j'ai remarqué. Imo, l'avantage d'économiser 100 Mo sur chaque installation d'application compense les petites augmentations de vitesse de temps en temps une fois qu'une nouvelle version de Chromium / Electron est sortie. De plus, une fois que nous avons intégré les développeurs, il ne devrait pas être trop difficile de réduire le temps entre les nouvelles versions du runtime. Nous pourrions alors prendre en charge la dernière version du runtime et une ou peut-être deux plus anciennes.

Reconstruire les fichiers .node tous les 6 mois ne devrait pas non plus être trop difficile, je suppose

Electron-builder prendra en charge une nouvelle option pour toutes les cibles nsis - useSharedElectronRuntime. Pour l'instant, toutes les dll existantes le seront, je pense qu'il est possible de réduire la taille des exe et de déplacer le code vers les dll, mais cela peut être fait plus tard, économiser 30Mo est déjà un bon objectif.

1. Créez un assemblage signé pour toutes les dll électroniques et publiez-les dans les versions de GitHub (le bac à puces n'est pas une option, car il n'est pas fiable).
2. Le programme d'installation de Nsis téléchargera et installera l'assembly s'il n'est pas encore installé. Sécurité — l'assemblage est signé. Electron-builder prend également en charge l'installation par machine. Et Windows fournit un niveau de sécurité supplémentaire si l'assemblage est installé par machine, donc, si besoin, vous pouvez l'activer. Une option supplémentaire sera ajoutée pour installer l'assemblage par machine dans tous les cas. Pas encore clair - devrait-il être vrai ou faux par défaut. Je pense que c'est faux, pour s'assurer que l'application électronique par défaut peut être installée sans administrateur.
3. pas besoin de s'inquiéter du temps d'exécution des électrons inutilisés - la dll partagée prend en charge le comptage des références. Lors de la désinstallation de l'application, l'assemblage sera supprimé et Windows le supprimera si aucune autre application ne l'utilise.

@CiriousJoker Re : sécurité. Je ne pensais pas aux problèmes de sécurité où l'application elle-même est malveillante. Je pensais aux applications électroniques qui aspirent et utilisent du contenu non fiable. c'est-à-dire à chaque fois qu'une application électronique affiche une page Web à partir du Web ouvert dans un webview ou similaire.

De nombreuses applications ne s'exposent pas au Web ouvert, et elles fonctionneraient bien sur un électron plus ancien. Mais l'autre extrême est quelque chose comme Brave qui, en tant que navigateur Web, ne fait rien d'autre que s'exposer. :-)

@sedwards2009 vous, mais si nous commençons à prendre soin de tout le monde et de leur maman, nous ne ferons aucun progrès. Il y aura toujours des raisons de ne pas faire quelque chose. Ne pas avoir 100% des développeurs à bord n'est qu'un sacrifice que nous devons faire. S'ils ont vraiment besoin/veulent de la sécurité, ils peuvent l'avoir manuellement.

En ce qui concerne le choix d'un LTS, le choix le plus judicieux à mon humble avis est de nous lier à Nodejs LTS, c'est-à-dire quelle que soit la version de l'électron correspondant au nœud LTS est effectivement l'électron LTS. Cela pourrait apporter une certaine harmonie et un accord pour que nous puissions avancer collectivement et avoir une certaine caution plutôt que de laisser cela au libre choix (qui nie cette communauté) ou de se disputer (qui ne nous mène nulle part).

@CxRes Mais quelle version d'Electron prenons-nous en charge ? Dans mon projet, le principal problème était de reconstruire les fichiers .node par rapport à la version spécifique d'Electron (pas de Node).

Nous pourrions simplement définir la dernière version d'Electron comme lts ou utiliser celle qui est la plus largement utilisée.

Est-ce que j'ai râté quelque chose? Imo, le problème est Electron, pas Node

Ok, laissez-moi essayer d'expliquer cela à nouveau avec un exemple:

• Node LTS est actuellement sur 6.11.1
• Par conséquent, nous voulons utiliser la version la plus élevée de l'électron qui a été officiellement construite avec la version la plus élevée du nœud qui satisfait la condition <= 6.11.1 > = 6.0.0
• La version la plus élevée de l'électron construit à l'aide du nœud 6 est l'électron 1.4.15 qui est construit avec le nœud 6.5.0
• Donc, l'électron 1.4.15 est l'endroit où nous bifurquons pour l'électron LTS et nous le reconstruisons avec 6.11.1 (et ainsi de suite jusqu'à ce qu'il y ait de nouvelles versions de Node v6)

Lorsque Node LTS passera à la v8 (LTS ne sont que des nombres pairs), nous migrerons ensemble vers un électron encore inédit qui sera construit à l'aide de Node v8 ou restera sur le fork LTS actuel jusqu'à ce qu'une telle version électronique soit publiée.

Qu'en est-il des développeurs qui veulent le dernier et le meilleur ?

@CxRes @CiriousJoker Evitons le hors sujet ici. Aucune raison technique n'empêche l'utilisation de différentes versions d'Electron. La fragmentation sera dans tous les cas (le développeur a publié l'application il y a un an et a oublié, une autre application d'un autre développeur est sortie récemment et utilise une autre version).

@YurySolovyov L'idée même de LTS est qu'il n'est pas le plus récent et le meilleur - son écurie. Et si nous ne pouvons pas accepter de nous concentrer sur une seule solution, nous sommes condamnés à souffrir de la sous-optimalité de Pareto de ne pas avoir de temps d'exécution car aucun groupe n'a le temps et la capacité de reconstruire chaque version et de les filtrer pour les bogues.

Voir également le commentaire de @CiriousJoker ci-dessus :

vous, mais si nous commençons à prendre soin de tout le monde et de leur maman, nous ne ferons aucun progrès.

@develar D'accord. Mais comme vous le soulignez, ce n'est pas un problème technique, c'est politique (se mettre d'accord sur une version qui fonctionne pour la plupart des gens de manière cohérente, de sorte que le fardeau soit partagé).

Donc que faisons-nous maintenant? Choisissons-nous une version lts et commençons-nous ou essayons-nous de trouver une solution pour que cela fonctionne pour tout le monde en essayant de créer un environnement d'exécution unique avec des dll modulaires (comme le suggère @develar si j'ai bien compris)

@CiriousJoker Assemblage côte à côte pour une version électronique particulière. par exemple ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 .

@develar Je ne trouve pas ce truc d'électronruntineassembly sur Google, pourriez-vous fournir un lien ou qchose ?

Imo, pour accélérer les choses, nous devrions simplement choisir une version Electron aléatoire comme version lts et commencer. Nous pouvons quand même changer la version à tout moment par la suite.
@develar Je ne sais toujours pas ce que vous voulez dire avec cet assemblage côte à côte, mais cela doit fonctionner sur plusieurs plates-formes et j'imagine que nous pouvons également l'implémenter plus tard.

Nous (ou en fait vous les gars) en parlons depuis des années, mais si personne ne commence, rien ne changera et nous resterons assis ici pendant encore 3 ans à discuter d'idées et à trouver des moyens de ne pas commencer.

J'espère que les développeurs d'électrons pourront résoudre la séparation de l'environnement d'exécution et de l'application dès que possible, ce qui favorisera grandement les applications électroniques, et je verrai un avenir radieux.

Ils ne l'ont pas résolu pendant ce qui me semble être des années, donc je suis un peu pessimiste à ce sujet. Bien sûr, ce serait génial, mais y travaillent-ils même activement?

@CiriousJoker Comme indiqué ci-dessus, je travaille sur le support d'exécution d'électrons partagés pour Windows dans le constructeur d'électrons. J'ai déposé https://github.com/electron-userland/electron-builder/issues/1942 pour suivre les progrès. J'espère qu'il sera prêt à l'emploi dans 1 mois.

@develar Mon mauvais, a dû l'oublier .. Dans ce cas, bonne chance, ce serait génial si vous pouviez y arriver!

Si quelqu'un est intéressé par la déduplication de segmentation définie par le contenu du sous-fichier mentionnée plus haut dans le fil de discussion dans https://github.com/electron/electron/issues/673#issuecomment -157980607, je l'ai ouvert : https:// github.com/ronomon/deduplication

Ce long fil est en sommeil depuis les derniers mois, mais je pense que le problème qu'il résout mérite toujours d'être étudié. Pendant le week-end, j'ai créé un petit utilitaire minimal d'une page pour renommer des fichiers en masse. Rempli d'électron-builder, le fichier final Mac .app fait 121 Mo ...

Je pensais à ce problème dernièrement. Ensuite, j'ai jeté un coup d'œil à mon smartphone : l'application Facebook fait 600 Mo. Chrome fait 325 Mo, Mesenger fait 300 Mo... Donc une application de 120 Mo sur le bureau, je m'en fous...

La taille n'est plus un problème aujourd'hui. RAM et la consommation d'énergie est.

_edit : si vous n'êtes pas d'accord, n'hésitez pas à partager pourquoi_

Pour la plate-forme Windows, les efforts de @develar avec electron-builder (electron-userland/electron-builder#1942) semblent proches de la réalisation d'un runtime partagé.

A également remarqué que le catalogue Web de l'application, qui regroupe les applications Web en tant qu'applications Electron autonomes, a résolu le problème de l'utilisation d'un environnement d'exécution partagé, afin de réduire considérablement la taille de l'application : webcatalog/webcatalog/issues/171. Cela a été fait dans leur packager, en créant des liens symboliques entre les ressources partagées entre les applications .

Les applications Web progressives (PWA) sont une solution partielle à ce problème. Sur Android, vous pouvez ajouter PWA à l'écran d'accueil et il agira comme un véritable apk. L'équipe Chrome travaille maintenant pour permettre aux PWA d'être installés sur le bureau (http://www.androidpolice.com/2017/12/05/google-wants-progressive-web-apps-replace-chrome-apps/), Microsoft montre également de l'intérêt pour la prise en charge des PWA (https://www.windowscentral.com/faq-progressive-web-apps-windows-10) et j'espère que Firefox et Safari se rattraperont bientôt. Les API manquantes (par exemple, l'accès au système de fichiers natif) seront ajoutées si les développeurs manifestent leur intérêt.
La plupart des applications Web Electron peuvent facilement être converties en PWA, mais je ne suis pas sûr de celles comme Atom, VSCode - le code natif devra probablement être réécrit dans WebAssembly.

@develar a des progrès sur cette idée ?

Je l'utiliserai dès sa sortie !

Ayant récemment rencontré cela, je voulais juste donner mon avis. Je n'ai cependant pas lu tout le numéro, donc je peux répéter certaines choses sans le savoir.

Je pense que quelque chose comme ça est très important, car bien que la taille d'un programme Electron puisse ne pas sembler si importante maintenant, vous commencez vraiment à le voir lorsque vous distribuez un programme très simple et petit - disons, une calculatrice personnalisée. Dans ce cas, quelque chose comme 5-10 Mo serait raisonnable. 60 Mo ou plus serait tout simplement ridicule. Pour un programme plus important, la taille d'Electron elle-même devient plus ignorable, mais cela peut toujours être ennuyeux.

Maintenant, un tel mode d'exécution nécessiterait cependant un certain type de système de version LTS compte tenu du taux actuel de versions. Les développeurs pourraient alors être encouragés à dépendre d'une version LTS, et une liste des versions les plus courantes utilisées pourrait même être affichée dans le répertoire des applications, les encourageant à utiliser la plus courante à moins qu'il ne manque une fonctionnalité requise.

Le mode d'exécution lui-même devrait, IMO, avoir un système intégré pour installer également d'autres versions de la bibliothèque Electron, de sorte que si l'utilisateur demande d'installer une application qui nécessite une version différente, le programme d'exécution peut alors la télécharger automatiquement en un simple étape du processus d'installation.

Je pense qu'il convient également de noter que l'utilisation de la RAM des applications Electron pourrait également être améliorée avec l'aide de cela, bien que les changements nécessaires pour le mettre en œuvre seraient beaucoup plus importants. Avec un environnement d'exécution partagé, les applications Electron utilisant la même version pourraient partager certaines ressources dans la mémoire.

Quoi qu'il en soit, je suis de toute façon très nouveau dans toute la source du projet Electron, donc désolé si quelque chose n'était pas clair, ou si j'ai répété quelque chose inutilement. J'espère vraiment que cela sera mis en œuvre, car cela ferait vraiment d'Electron une plate-forme beaucoup plus prometteuse pour encore plus de types de programmes. :+1:

@octacian Je commence à penser que les PWA sont une meilleure option. Pas universel, cependant - vous ne pouvez pas tout faire avec PWA - mais certainement pour des choses comme les calculatrices personnalisées, ils devraient être plus que suffisants.

Il ne nous reste plus qu'à attendre que le support PWA sur le bureau émerge.

Je pense également qu'avec un tel système, 1- il sera plus facile d'expédier vers des systèmes embarqués/plus petits, et 2- dans le futur, une base de système d'exploitation de type électronique pourra être créée pour les appareils mobiles.

@yasinaydin Il existe déjà LG WebOS. (Il y avait aussi Firefox OS, mais il n'est plus utilisé)

@KeitIG ​​Mon monsieur, votre argument serait absolument décent si le seul problème avec Electron était sa taille. Avoir un programme légèrement plus grand mais simplifier la complexité et la possibilité d'échec pour les développeurs (nous ne pouvons pas nier qu'Electron est génial pour donner aux développeurs un moyen standardisé de créer des applications sans trop de place pour bousiller) serait génial. Hélas, l'utilisation d'une version distincte des bibliothèques pour chaque application signifie également une utilisation accrue de la RAM et des problèmes de sécurité distribués (et plus difficiles à résoudre). J'avais mieux expliqué cela dans mon problème en double , mais en un mot, je pense vraiment qu'une bibliothèque d'exécution partagée que vous pouvez mettre à jour par elle-même et partager entre différentes applications Electron (qui seraient également livrées dans une version "lite", un peu comme quand certains développeurs distribuaient des fichiers Java à utiliser sur votre JVM et regroupaient .exe s) seraient vraiment le facteur décisif pour Electron, et même si je comprends que ce serait probablement une énorme quantité de travail, cela m'attriste que ce n'est pas encore dans les plans des développeurs. Espérons qu'ils le fassent à l'avenir.

@dre-hh Bien que je reconnaisse la bonne intention de votre proposition, elle est, entre autres, trop restrictive. Par exemple, j'ai développé une application électronique commerciale pour mon employeur, et elle est utilisée dans des environnements très réglementés (pas de connectivité Internet, exigences de traçabilité / audit, etc.). Nos clients ne peuvent pas nous permettre de faire des choses comme la mise à jour automatique du logiciel. C'est un monde très différent des applications Web typiques pour les masses. Les navigateurs Evergreen et l'installation automatique des mises à jour de sécurité du système d'exploitation sont, à mon avis, une excellente idée pour la plupart des gens dans la plupart des cas, mais mon point est qu'ils ne conviennent pas partout. Parfois, le risque d'interruption causé par un changement de logiciel est bien supérieur au risque associé à l'exécution d'une version obsolète du logiciel, en particulier dans les environnements contrôlés où d'autres techniques d'atténuation de la sécurité sont en place. Par conséquent, prendre une mesure extrême telle que bloquer l'exécution d'applications utilisant des versions obsolètes d'électron (ou vraiment, n'importe quelle bibliothèque) n'est pas une solution idéale, voire pas du tout. (De plus, les administrateurs disposent déjà de nombreux contrôles pour restreindre les programmes pouvant être exécutés, afin qu'ils puissent l'implémenter sans aucune nouvelle fonctionnalité du système d'exploitation.)

De plus, comme pour la plupart des problèmes de sécurité, une grande partie du problème provient de développeurs qui ne sont pas conscients des risques ou qui ont choisi, pour une raison quelconque (par exemple, le manque de temps), de ne pas suivre les directives de sécurité pour les outils qu'ils utilisent. (par exemple , la sécurité, les capacités natives et votre responsabilité ) En tant que développeurs, nous devons tous faire notre part pour assumer la responsabilité de la qualité (qui inclut la sécurité) de notre travail.

Enfin, je pense que c'est une erreur de se tourner vers une entité logicielle commerciale, telle que Microsoft, pour répondre à ces préoccupations. C'est en partie parce que, comme on vient de le dire, nous ne pouvons pas nous attendre à produire des applications sécurisées via des développeurs qui ne sont pas soucieux de la sécurité. Plus important encore, à mon avis du moins, l'une des belles choses d'Electron est sa nature open source et multiplateforme, qui ne sont généralement pas des priorités pour les éditeurs de logiciels commerciaux. Des progrès bien pensés et réussis nécessiteront très probablement un certain niveau de consensus et d'efforts de la part de l'ensemble de la communauté des développeurs. Bien sûr, les contributions des entités commerciales sont, bien sûr, appréciées.

@jacobq Au cas où vous ne le sauriez pas, Microsoft est le propriétaire d'Electron.

Au cas où vous ne le sauriez pas, Microsoft est le propriétaire d'Electron.

@Jop-V Veuillez ajouter une citation pour cela ; Je ne pense pas que ce soit correct. La page d'accueil de electronjs.com dit:

Electron est un projet open source maintenu par GitHub et une communauté active de contributeurs.

Microsoft est un consommateur d'Electron (l'utilisant dans des produits comme Visual Studio Code) et (je présume) également un contributeur, mais ils n'en sont pas propriétaires. Le fichier de licence ne mentionne pas Microsoft et l'article de Wikipedia ne suggère pas non plus qu'ils aient une position de propriété.

@jacobq Microsoft va acquérir GitHub donc si Electron est actuellement maintenu par GitHub, il sera bientôt maintenu par Microsoft pour autant que je sache.

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

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

L'acquisition de Github par Microsoft ne signifie rien pour Electron. Github est/sera toujours une entreprise distincte, avec ses propres produits et projets. Je ne vois pas Microsoft devenir propriétaire d'Electron, autant que je ne vois pas Microsoft devenir propriétaire d'Atom.

Je pense que ce débat n'aide pas vraiment le point initial de la question.

https://github.com/GoogleChromeLabs/carlo

Carlo a l'air assez intrigant. Je l'ai essayé et c'est très intuitif. Quelqu'un a-t-il déjà expérimenté le pkg ing?

Pourquoi toutes les propositions visant à réduire la surcharge du disque dur et de la mémoire des utilisateurs finaux ne sont-elles jamais étudiées ? C'est une idée fantastique qui a 4 ans et qui n'est encore qu'une idée. Je ne comprends pas pourquoi ce genre de choses ne sont pas au sommet des priorités du projet

@ danielo515 parce qu'au lieu de créer un autre projet industrieux, il y a https://github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app

Qu'est-ce que tu racontes? C'est déjà un énorme chantier. C'est aussi le plus répandu et le plus utilisé, donc pointer les gens vers un projet différent pour une fonctionnalité qui devrait faire partie de celui-ci ne me semble pas correct.
De plus, Carlo c'est une approche différente, ils utilisent votre Chrome installé, donc ce n'est pas comme une version démon d' Electron .

Je ne comprends pas pourquoi ce genre de choses ne sont pas au sommet des priorités du projet

Parce qu'en faire une réalité est difficile (comme "vraiment" difficile).

Si vous n'êtes pas satisfait (ce qui est tout à fait compréhensible), n'hésitez pas à bifurquer Electron et à soumettre un PR.

Ne vous méprenez pas, s'il y avait une solution simple à ce problème, je suis sûr qu'elle aurait déjà été implémentée.

@ danielo515

... diriger les gens vers un projet différent pour une fonctionnalité qui devrait faire partie de celui-ci ne me semble pas correct.

Je pense que le fait est que chaque projet a ses forces et ses faiblesses, et Carlo est bien adapté aux cas à espace restreint. Pour mes cas d'utilisation, une taille d'application de 100 Mo convient parfaitement, donc même si j'aimerais voir cette fonctionnalité atterrir, les autres fonctionnalités électroniques sont beaucoup plus importantes pour moi.

@jacobq Oui, vous avez raison - différents cas d'utilisation nécessitent différents outils.

Si quelqu'un d'autre est intéressé, j'ai créé une liste d'outils similaires pour développer des applications js sur le bureau.

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

Je n'utilise tout simplement pas Electron parce que je ne peux pas me permettre de mettre à jour des dizaines d'applications de 100 Mo - et vous savez comment les applications doivent être mises à jour (j'ai d'autres opinions à ce sujet, mais les partager n'aidera pas).
Ce que j'aime vraiment dans l'approche de Carlo, c'est l'idée d'utiliser le navigateur installé.
Mieux encore, Carlo pourrait sûrement utiliser n'importe quel navigateur disponible, pas seulement chromium, car le marionnettiste peut également gérer d'autres navigateurs. Sur OSX, vous lancez Safari, sur linux epiphany(webkitgtk) ou firefox, etc...
Donc, vraiment, pour obtenir une application, vous n'auriez qu'à installer nodejs et votre application.
Maintenant, la question va être : à quel point pkg peut-il être bon pour utiliser les bibliothèques installées sur le système et les addons natifs ?
Par exemple, si je devais empaqueter l'application que je développe actuellement, j'aurais besoin de postgresql, sharp (et vips), webkitgtk et exiftool. J'aimerais pouvoir distribuer l'application uniquement aux utilisateurs Linux debian, fedora ou ubuntu. J'aimerais m'en tirer avec les "offres groupées folles" et capitaliser à la place sur le travail acharné effectué par ces distributions, gratuitement.

@kapouer ... utilisez le navigateur installé ...

Bien qu'en théorie une bonne idée, cela entraîne une difficulté accrue dans le codage des applications côté Web, car vous devriez maintenant vous concentrer sur la prise en charge de plusieurs navigateurs et les navigateurs sur lesquels ils se rabattent peuvent être limités dans ce que vous souhaitez faire car ils n'ont pas de support complet pour des choses comme celles que vous pouvez trouver dans Chromium. Vous comptez également sur l'utilisateur pour vous assurer que son navigateur est à jour et que les multiples fournisseurs de navigateurs ne cassent pas votre application avec une mise à jour.

De nombreux utilisateurs ont réussi à avoir des mises à jour massives de 50 Mo en passant aux mises à jour delta ou en demandant aux gestionnaires de packages de ne mettre à jour que le fichier .asar ou les dossiers de ressources. Et ne faites une grande mise à jour Electron que lorsque cela est nécessaire. C'est ce que nous faisons dans notre entreprise et cela a très bien fonctionné.

Du point de vue d'un utilisateur naïf, l'utilisation du shell d'application Electron en tant que runtime partagé rendrait la distribution et l'utilisation très faciles. Pour par ex. Avec 5 applications électroniques dans un seul système, vous avez 5 instances d'app-shell et c'est environ 300 Mo, n'est-ce pas ?

Je crois fermement que l'électron est l'avenir de l'UX de bureau et que ce serait un grand pas en avant (regardez .NET Runtime - peut-être une mauvaise comparaison, mais c'est cool, non ?) pour rendre la technologie Web plus puissante.

Electron a déjà un runtime pour le développement, n'est-ce pas ? L'"électron". commande, je veux dire. Pourquoi ne pas réutiliser cela pour le côté utilisateur ?

Pour gérer plusieurs applications en fonction de différentes versions d'Electron, vous pouvez utiliser l'approche utilisée par le noyau .NET. Installez simplement plusieurs versions du runtime côte à côte et demandez aux applications de déclarer la version minimale (ou maximale) dont elles ont besoin.

J'ai créé un lanceur de preuve de concept : https://github.com/ProPuke/electron-shared

Exécutable unique, d'une taille inférieure à 1 Mo. Passez-lui un répertoire d'application ou un package asar et il vérifiera les exigences de votre version électronique dans votre package.json devDependencies et téléchargera/exécutera avec la version correcte.

Les runtimes Electron sont stockés dans AppData\Local\Local\electron-shared (windows) .cache/electron-shared (linux) Library/Application Support/electron-shared (mac) afin qu'ils puissent être partagés entre les applications.

Sans chemin spécifié, il exécutera automatiquement le répertoire app ou app.asar s'il en existe un ; Vous pouvez donc distribuer votre application uniquement avec ce fichier et app.asar . Ou cela pourrait être associé à des fichiers .asar et seuls les asars pourraient être distribués.

Il a également quelques paramètres de ligne de commande, notamment --downloadOnly et --silent afin qu'il puisse être appelé depuis les programmes d'installation pendant le processus d'installation.

Il ne gère pas la mise à jour automatique (il ne télécharge que si une version compatible d'Electron n'est pas déjà disponible sur votre machine), mais cela peut être fait périodiquement au lancement, ou par un service d'arrière-plan (tant que les runtimes sont placés dans le bon endroit où il trouvera et utilisera les dernières applications au lancement).

Savoir quand supprimer les anciennes copies des runtimes peut être délicat. Ils pourraient s'accumuler avec le temps. Nous aurions besoin de savoir quelles applications installées utilisaient quelles versions (et donc lesquelles n'étaient plus nécessaires) ou peut-être simplement de stocker une date de dernière utilisation pour chaque version d'exécution et de les supprimer automatiquement si elles n'ont pas été utilisées. dans un moment.

Quoi qu'il en soit, une preuve de concept/proposition. Est-ce que quelque chose comme ça résout les problèmes? Ai-je raté quelque chose de flagrant et d'évident ?

J'ai essayé le partage d' électrons de @ProPuke et j'ai pu exécuter une démo à démarrage rapide par électrons . Mais je n'ai pu exécuter aucune des applications décrites dans le site Web electronjs (parce que la plupart des applications utilisent un script shell pour démarrer l'application et pas seulement package.json, si je comprends bien). Mais je crois que cette _preuve de concept/proposition_ pourrait être un pointeur vers la prochaine grande mise à jour.

J'ai une idée. electron Parce que prend actuellement en charge la commande "chemin electron.exe". Je pense que vous pouvez l'ouvrir en appelant plusieurs asars à partir de la ligne de commande. Pour le moment, je ne suis qu'une idée. J'espère que quelqu'un pourra le faire, parce que je viens d'effleurer ce logiciel.
_____________ Version traduite en chinois__________
J'ai une idée. Parce qu'actuellement, electron prend en charge la commande "chemin electron.exe". Je pense qu'il peut être ouvert en utilisant la ligne de commande pour appeler plusieurs asars. Je ne suis qu'une idée pour le moment, j'espère que quelqu'un pourra y jeter un œil, car je viens d'être impliqué dans ce logiciel.

Après un bref aperçu de l'ensemble de la conversation (et d'autres discussions comme Multiple "apps"), je vais résumer - appeler plusieurs asars de manière native au lieu de commencer avec plusieurs binaires a une longue histoire, mais n'est pas pris en charge. Mais default_app d'électron est implémenté à l'aide de la ligne de commande (peut-être, je ne sais pas pour le moment). Je pense que l'appel de cmd via electron (cela semble être possible) devrait permettre d'obtenir la compatibilité de cette fonction.
En jetant un coup d'œil rapide à toutes les conversations (et à d'autres discussions, telles que Multiple "apps"), je conclus que les appels natifs vers plusieurs Asar au lieu de plusieurs binaires commencent, ce qui a une longue histoire, mais n'est pas pris en charge. une implémentation qui tire parti de la ligne de commande (et, peut-être, je ne sais pas depuis un moment).Je veux appeler cmd via electron (comme si je le pouvais) devrait pouvoir atteindre cette barre de compatibilité de fonctionnalité.

Dans le pire des cas, vous devrez créer un fichier .bat ou l'équivalent pour les systèmes d'exploitation autres que Windows et l'exécuter à partir d'Electron.

Liens éventuellement utiles :

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-example

Il semble que ce n'est que lorsqu'il n'y a pas de dossier app.asar ou app que se trouve l'électron de commande. chemin exe valide

Oh, vous devez donc avoir un électron pour exécuter le chemin exe à l'intérieur de l'électron utilisé pour configurer tout cela. Toujours mieux qu'une installation d'électrons pour chaque application utilisée. Vous n'auriez besoin que d'une seule installation d'électron pour chaque version d'électron dont votre application a besoin. Vous auriez probablement besoin de créer une extension distincte qui est une archive zip renommée qui contient à la fois l'application que nous essayons d'exécuter et un fichier avec la version recommandée (l'exécuterait tout de suite), les versions compatibles (demanderait si exécuter ou installer la version recommandée, et également télécharger la version recommandée d'Electron en arrière-plan), ou afficherait simplement une barre de progression de téléchargement, pour que la version recommandée soit téléchargée.

Ou j'ai mal compris quelque chose.

Cette idée est probablement la même : puisque bat est actuellement facile à dire, prenez-le par exemple, le contenu est electron.exe app1.asar, après exécution, electron ouvre le contenu de app1.asar. C'est probablement ainsi que cela fonctionne, mais lorsque vous écrivez la phrase suivante, electron.exe app2.asar, dans bat, vous ne pouvez le faire que lorsque l'électron de app1.asar se termine. Et quand la chauve-souris est éteinte, l'électron est éteint. Mais j'écris electron.exe app3.asar|electron.exe-v ou electron.exe app3.asar|start, et ainsi de suite. Quand je ferme la chauve-souris, l'électron peut survivre, mais je ne peux pas continuer à ouvrir d'autres asars. Je pense que ce programme autonome pourrait être meilleur que celui-ci, car bat est encore quelque peu limité.

Pas si vous utilisez des dossiers temporaires.

Vous avez les versions (archivées ou non archivées) dans un dossier electron_versions, à partir duquel vous utilisez soit la version recommandée, soit la version compatible la plus récente que vous avez téléchargée en copiant la version que vous utilisez dans un dossier temporaire, et après l'avoir terminé, vous supprimer le dossier.

Le chemin des fichiers enregistrés localement se trouverait soit dans le dossier electron, soit à côté du fichier que vous utilisez. Si vous l'utilisez à partir d'une archive contenant les éléments que j'ai mentionnés au cours des dernières 24 heures, vous devrez alors déplacer les fichiers de données sauvegardés dans l'archive, ou ne pas le déplacer du tout avant de supprimer ce dossier d'instance électronique temporaire.

SSD？

???

La raison de la suppression du dossier électronique temporaire est que l'application pourrait théoriquement modifier les fichiers de l'installation électronique sur laquelle elle s'exécute, et par conception. Je veux dire, l'archive peut contenir les fichiers et dossiers qui doivent être écrits ou écrasés à l'intérieur de l'installation électronique temporaire.

Ainsi, une fois l'installation utilisée, elle peut être considérée comme corrompue par l'application qu'elle a exécutée, elle ne peut donc pas être recyclée et doit donc être supprimée. Cependant, la version à partir de laquelle l'installation alors corrompue utilisée comme base est toujours intacte, dans le dossier electron_versions de l'application runtime-electron que nous essayons de créer.

En fait, si l'archive avec une extension distincte, que j'ai mentionnée précédemment, est en lecture seule, les données qu'elle utilise pourraient être déplacées vers %appdata%, théoriquement. Ainsi, une application exécutée à l'intérieur de l'électron en mode d'exécution que nous essayons de créer serait en fait portable (autonome), et donc copier ce fichier serait suffisant pour emporter la configuration de cette application avec vous.

Mais nous aurions aussi probablement besoin d'ajouter une fonction de mise à jour pour ce type de fichier, qui serait une autre installation électronique qui copierait et écraserait les fichiers du nouveau fichier d'installation sur une copie de l'ancien fichier d'installation, et renverrait le nouveau fichier d'installation avec le données dont il disposait. Le tout pourrait être fait automatiquement, s'il y a un lien de téléchargement dans les fichiers utilisés par l'électron en mode d'exécution que nous essayons de créer.

Une fois que c'est prêt, si vous voulez aller plus loin, vous pouvez même ajouter un client git à partir duquel mettre à jour les applications, bien que cela puisse nécessiter l'utilisation de github et bitbucket pour héberger les fichiers d'archives compilés.

vous pouvez utiliser le fichier de téléchargement "curl, wget, aria2c", et l'utilisateur n'a pas besoin d'installer git, oh, vous devez utiliser "gzip, 7z" décompressez le zip.

Je crée un outil electron-runtime qui fonctionne de la même manière que electron-builder . Il regroupe uniquement le fichier app.asar avec un simple script sh (plus tard, ce sera une interface utilisateur pour montrer la progression du téléchargement d'Electron). Actuellement, cela ne fonctionne que pour macOS.

Lors de l'exécution d'une application fournie avec electron-runtime , il télécharge essentiellement une version majeure correspondante d'Electron, mais la plus récente en cas de mineur et de correctif, car les changements de rupture d'Electron ne se produisent que par incréments de version majeure.

L'application electron-quick-start ne fait que 62 Ko, capture d'écran :

Si cela vous intéresse, laissez une étoile, une communication ou un problème.

J'ai un peu mis à jour le paquet, qu'il peut construire en utilisant electron-builder ( Voici comment cela fonctionne ). Alors maintenant, vous pouvez créer même Visual Studio Code avec ! (mais toujours uniquement sur macOS).

J'ai sorti avec succès une première version de electron-global ! (Je l'ai changé, puisque electron-runtime a été pris). Vous pouvez créer votre application en utilisant mon package npm avec electron-builder . J'ai également ajouté une interface utilisateur avec une barre de progression pour afficher la progression d'un téléchargement Electron. J'espère que cela deviendra plus populaire pour améliorer Electron.

Je suis désolé, j'utilise le système Windows et je n'ai pas l'argent pour utiliser MacOS. Mais je pense que votre projet sera très réussi.

@nwdxlgzs Il prend en charge Windows, macOS et Linux...

Je pensais que ce projet ne supportait que MAC.
Je vais prendre le temps d'essayer ce super projet.

Merci de l'avoir fait et de nous tenir au courant!
J'utilise aussi Windows.
Je regarderai le code quand j'aurai le changement.

Eh bien, que diriez-vous d'intégrer electron-global en amont et d'en faire la nouvelle valeur par défaut 😏