+100, Das wäre sehr sehr hilfreich, um die Größe der App zu reduzieren.

Kann die Erweiterung .asar geändert werden? Auf Ungarisch hört sich das komisch an. Im Grunde würde es the shit schlecht bedeuten ( Link ).

.apak? bei allem Ernst, es gibt Unmengen von Sprachen, daher kann fast jede Erweiterung in einigen von ihnen seltsam klingen.

Die Installation und Aktualisierung der IMO-Laufzeitumgebung sollte so einfach wie möglich sein. Viele Laufzeiten haben sehr nervige Benachrichtigungen. Wenn Sie dies tun möchten, sollten außerdem einige zusätzliche Manifest-Metadaten bereitgestellt werden, da neuere App-Versionen möglicherweise nicht mit der alten Laufzeit funktionieren, sodass Sie die aktuelle Laufzeitversion mit der Version im App-Manifest vergleichen müssen (möglicherweise sogar im Bereich der Versionen wie in node packages ) und wenn die Laufzeit aktualisiert werden muss, machen Sie diesen Vorgang so einfach wie möglich. Ich weiß nicht, was für die meisten Leute einfach ist, aber für mich ist es nur ein Fenster mit Fortschrittsbalken oder Statusmeldungen ("Downloading... 57%", "Updating...")
Ich bin mir nicht sicher, aber Hintergrundaktualisierungen können ebenfalls in Betracht gezogen werden. Es kann sich um einen Update-Dienst handeln oder nur um einen Runtime-Download, während die App ausgeführt wird, und um ein Update, wenn die App geschlossen wird.

+1 dafür. Ich arbeite an einer Anwendung, die ich für Mac und Windows liefern muss, und dies würde die Lieferung erheblich vereinfachen.

Das wäre toll!

Ein paar Gedanken:

• Wie @YuriSolovyov sagte, brauchen wir einen Weg, um anzugeben, mit welchen Versionen der Atom-Laufzeit ein bestimmter Asar kompatibel ist. Vorzugsweise sollte dies auch die Angabe einer genauen Version ermöglichen, da dies die QA bei der Veröffentlichung einer asar-basierten App entlastet.
  
  
  
  • Um dies zu unterstützen, müssten wir zulassen, dass mehrere Versionen der Atom-Runtime nebeneinander installiert werden, möglicherweise unsichtbar für den Benutzer.
  
  
  • Beachten Sie, dass dies etwas im Widerspruch zu den Idealen der Begrenzung der Downloadgröße steht. Ein Unternehmen, das mehrere Asar-basierte Produkte herstellt, könnte jedoch intern standardisieren, sodass alle seine Apps immer noch dieselbe Version verwenden.
  
  
• Sie haben die Unterstützung für die automatische Aktualisierung der Atom-Runtime auf dem Mac nicht erwähnt, aber das wäre _sehr_ nützlich.
• Anstatt Nur-Quellen-Installationen unter Linux zu haben, wäre es gut, die Installation/Aktualisierung von Binärdateien zu unterstützen, sowohl durch .deb/.rpm-Pakete als auch durch eine Methode, die keine sudo-Rechte zur Installation erfordert (dh pro Benutzer). Für Laufzeiten, die pro Benutzer installiert werden, wäre die automatische Aktualisierung ebenfalls sehr nützlich.
• Würde es eine Unterstützung geben, installierte Asar-Dateien auf dem neuesten Stand zu halten - oder müsste das in jeder App unabhängig implementiert werden?

Zu guter Letzt, was ist der Zeitplan für diese Bemühungen? Was wäre der beste Weg, um loszulegen, wenn ich mit der Implementierung von Teilen davon beginnen möchte? Ich bin offen für Beiträge.

@joshuawarner32 Derzeit ist dies nur eine grobe Idee, ich habe vor, daran zu arbeiten, nachdem ich einige wichtige Probleme der Atomhülle gelöst habe, aber es könnte Monate später sein.

Ich denke, es lohnt sich auch, sich bestehende Runtimes anzuschauen und wie sie funktionieren/aktualisiert werden, wie störend sie sind und welche anderen Vor- und Nachteile sie haben.

Derzeit ist dies nur eine grobe Idee, ich plane, daran zu arbeiten, nachdem ich einige wichtige Probleme der Atomhülle gelöst habe, aber das könnte Monate später sein.

Es ist ungefähr 5-6 Monate her. Es wäre toll, dies umzusetzen.

Wir haben eine interne Implementierung dafür aufgebaut, die sehr gut zu unserem speziellen Anwendungsfall passt, und wir können sie möglicherweise vorschalten. Die Gefahr wäre, dass es tatsächlich zu spezifisch für unseren Anwendungsfall ist und niemand sonst an der zusätzlichen Komplexität interessiert wäre.

Hier sind die Highlights unseres Designs:

• Stellen Sie .asar.gz-Dateien für mehrere verschiedene Apps auf einem Server bereit
• Verteilen Sie einen einzelnen Atom-Shell-Build an Benutzer, der keinen Code für bestimmte Apps bündelt
• Laden Sie beim Start der App die entsprechende .asar.gz-Datei herunter (falls sie nicht vorhanden ist oder eine neuere auf dem Server vorhanden ist). Extrahieren Sie es und führen Sie die enthaltene App aus.
• Unser Atom-Shell-Build akzeptiert ein --app -Argument, um anzugeben, welche App heruntergeladen/ausgeführt werden soll

Ist das etwa das, was die Atomhüllen-Leute im Sinn hatten? Wäre so etwas für andere Menschen nützlich?

Wie die JRE könnte es die ERE (Elektronen-Laufzeitumgebung) sein, mit .eapp-Dateien (Elektronen-App)

-1 für .eapp

+1 Ich brauche es!

Unter Windows können wir Installer und Auto-Updater für Atom-Runtime bereitstellen und den damit zu öffnenden .asar-Dateityp registrieren.

Installieren Sie Steam unter Windows und sehen Sie sich an, wie sie Spielverknüpfungen erstellen, sie verwenden tatsächlich einen Protokoll-Handler, es ist relativ clever

:+1: auf dem Steam-Modell.

Es gibt kein technisches Hindernis bei der Implementierung, das Ganze kann einfach eine Electron-App selbst sein. Aber das Problem ist, dass es auch nicht einfach zu implementieren ist, unter Berücksichtigung aller Details, ich denke, es erfordert ein kleines Team, das Vollzeit daran arbeitet, ich bin mir nicht sicher, ob es jemals passieren würde.

Aber das Problem ist, dass es auch nicht einfach zu implementieren ist, unter Berücksichtigung aller Details, ich denke, es erfordert ein kleines Team, das Vollzeit daran arbeitet, ich bin mir nicht sicher, ob es jemals passieren würde.

Es gibt viele Fragen in meinem Kopf, die, obwohl sie sicherlich nicht unüberwindbar sind, diesen Plan schwierig machen. Angenommen, „App 1“ erfordert 0.30.x und kann nicht auf 0.31.x ausgeführt werden, und „App 2“ erfordert das Gegenteil. Wer gewinnt in diesem Szenario?

Es scheint eine Menge Aufwand und Infrastruktur / Kniffe zu sein, etwas zu optimieren, das nicht unser größtes Problem ist - Speicherplatz und Bandbreite, auf Kosten der Entwicklerkomplexität (dh jetzt müssen Entwickler dieses verrückte Ketteninstallationsprogramm erstellen, um es zuerst zu installieren / verifiziere Electro und installiere dann ihre App)

Ich will mich nicht über eine Idee aufregen! Ich denke nur, dass wir die Zeit, die wir dafür brauchen würden, stattdessen für unser großes Problem aufwenden könnten – es für neue Entwickler superleicht zu machen, Electron-Apps zu erstellen und zu veröffentlichen, von der ersten Codezeile bis hin zu Versand an Benutzer

@paulcbetts Aber hey, die Vorteile sind es wert, oder? Beim Aktualisieren einer App müssen Benutzer weniger als 1 MB statt ~70 MB herunterladen. Das bedeutet, dass wir nicht einmal automatisch aktualisierende Frameworks und alles brauchen, wir müssen nur ein Mikro-Zip-Archiv mit ein paar Dateien herunterladen und extrahieren.

Ich habe die letzten drei Monate in einem abgelegenen Gebiet verbracht, wo die Geschwindigkeit weniger als 128 kbps betrug, und glauben Sie mir, die Größe des Upgrades ist eine große Nervensäge, das Schlimmste ist, dass es immer noch Tonnen von Menschen gibt, die sich noch in ähnlichen Situationen befinden

Das heißt, wir brauchen nicht einmal automatisch aktualisierende Frameworks und alles, wir müssen nur ein Mikro-Zip-Archiv mit ein paar Dateien herunterladen und extrahieren.

Ich glaube jedoch nicht, dass das stimmt, denn mit ziemlicher Sicherheit werden Sie irgendwann ein Update auf eine neuere Version von Electron einführen wollen, und dann kerplowie, Sie befinden sich in einer ähnlichen Situation (oder zumindest einer, die ähnlich hässlich ist). )

Einfache Apps sind jetzt zwischen 30 und 50 MB groß, es sei denn, Sie haben eine Menge Videos in Ihrem Paket. Ich glaube nicht, dass das für die meisten Leute eine Strecke zum Herunterladen ist. Ich glaube, das durchschnittliche YouTube-Video ist zwischen 30 und 40 MB groß ...

Ich möchte hier nur anmerken, dass die Verbindungsgeschwindigkeit in China im Durchschnitt etwa 20 kB/s beträgt (zugegeben, ich habe eine langsamere Verbindung als ~92 % meiner Stadt). Das Aktualisieren von Atom/Electron erfordert normalerweise einen ganzen Tag wget -c 'ing. es sei denn, die Taobao-Spiegel werden verwendet.

Aus Gründen der Versionskompatibilität bewegt sich die Entwicklung von Electron zu schnell, um auch eine Catch-All-Version zu haben. Vielleicht könnte eine Art Wrapper/Helfer verwendet werden, um die angeforderte Hauptversion zu verwenden/herunterzuladen, wenn die App startet?

20kbit/s? wie kannst du überleben? Ich kann mir nicht vorstellen, wie schwierig das die Dinge machen muss!

@steelbrain nicht meine Absicht

@RIAEvangelist Schnell vorankommen und viel Geduld. Die Geschwindigkeit wird spät in der Nacht sehr schnell, also lassen Sie Downloads einfach laufen oder planen, während Sie schlafen. :3

Wie auch immer, ich denke, es wäre nicht zu viel Arbeit, einen (einfachen) Drittanbieter-Wrapper zu schreiben, möchte jemand es versuchen?

.asar-Dateien können ihre Elektron-Version jedoch nicht ohne weiteres deklarieren. Vielleicht wäre ein anderes Programmdeskriptorsystem erforderlich?

Wie wäre es mit einer Art Runtime-Versions-Dispatcher, der die für Ihre App erforderliche Runtime-Version (bei Bedarf herunterlädt und) startet? Dafür können wir einen Eintrag in package.json hinzufügen.

@YuriSolovyov Abgesehen davon, dass wir nicht standardmäßig .json-Dateien zur Laufzeit verarbeiten können. Ich nehme an, es könnte zuerst die asar-Datei lesen und package.json anzeigen, aber das würde es ein wenig verlangsamen.

@Tribex ja, Logikfluss ist wie:

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

Im Idealfall sollte der Laufzeitmodus ähnlich funktionieren wie der Steam- oder Chrome-App-Launcher . Das Hauptproblem ist, wie wir mit Apps umgehen, wenn die Laufzeit auf eine neue Version aktualisiert wird.

Electron-Apps leiden unter dem Upgrade von Electron, insbesondere knotennative Module. Die nativen Module müssen aufgrund des C++ ABI-Problems für jedes Upgrade von Electron neu erstellt werden (es gibt mehrere von Benutzern gemeldete Absturzprobleme, die vergessen wurden).

Steam leidet nicht darunter, da jedes Spiel auf Steam ein eigenständiges Programm ist, tatsächlich können Sie das Spiel ohne Steam Client starten. Chrome App Launch auch nicht, da Chrome-Apps in HTML/JS/CSS geschrieben sind, bei denen es sich um interpretierte Sprachen handelt, gibt es keine Lücken in verschiedenen Versionen von Chrome.

@hokein wie wäre es, wenn wir einen leichten "Client" in einer Muttersprache hätten, der mehrere Sprachen herunterlädt, wenn er auf eine App trifft, die von einer deinstallierten Version von Elektron abhängt, lädt er eine Kopie davon herunter und führt dann jede App mit ihrem spezifischen Elektron aus.

Es gibt ungefähr einmal pro Woche eine neue Electron-Version, daher ist die Wahrscheinlichkeit gering, dass 2 Apps genau dieselbe Version von Electron haben.

Um einen Laufzeitansatz zu unterstützen, müssen wir wahrscheinlich damit beginnen, Releases in LTS-Versionen (Long Term Support) und Bleed-Edge-Versionen zu trennen. Das LTS wird für die Produktion und die Bleeding Edge für die Entwicklung und das Testen verwendet. LTS wird nur Fehlerbehebungen und möglicherweise einige Änderungen erhalten, die die Hauptversionen von io.js und Inhaltsshell nicht ersetzen, sodass native Module weiterhin funktionieren sollten.

Angesichts dessen, was @etiktin gesagt hat, würde die Downloadzeit wahrscheinlich keinen Vorteil bringen, es sei denn, ein Benutzer hat viele Elektron-Apps auf seinem System, da er die Laufzeit immer noch fast jedes Mal herunterladen müsste.

In den zwei Wochen, in denen ich mir Electron angesehen habe, habe ich, glaube ich, 4 Veröffentlichungen gesehen.

@etiktin Wenn Elektron auf Semver folgt, könnte eine App im Idealfall die Version ^ 0.31 deklarieren und die neueste Version 0.31.x verwenden. Das hilft vielleicht etwas weiter.

Wir haben eine App in Produktion mit einem Semver-Auto-Update-Mechanismus, der Folgendes tut:

1. GET einen einfachen HTTP-Endpunkt auf dem Server, der die aktuelle Version (0.3.0, 0.3.1 usw.) und die Plattform (darwin-x64, win32-ia32, win32-x64 usw.) der App angibt.
2. Der Server gibt „304 Not Modified“ oder ein JSON-Manifest zurück, wenn es eine neuere Version gibt.
3. Das JSON-Manifest ist im Wesentlichen eine verschachtelte Liste von Ordnern, Dateien und Symlinks in der neueren Version.
4. Ein Ordnereintrag im JSON-Manifest sieht folgendermaßen aus: [Name, Array von untergeordneten Einträgen].
5. Ein Dateieintrag im JSON-Manifest sieht folgendermaßen aus: [Name, Hash des Inhalts, Array von Hashes des Inhalts, aufgeteilt in 64-KB-Blöcke, ein Integer-Flag, das angibt, ob die Datei ausführbar ist oder nicht].
6. Ein Symlink-Eintrag im JSON-Manifest sieht folgendermaßen aus: [Name, Zielpfad].
7. Diese JSON-Manifeste werden für jede Version auf dem Server erstellt und zwischengespeichert. Für jede Datei im JSON-Manifest führt der Server einen einfachen Deduplizierungsalgorithmus aus, um die Datei mithilfe von inhaltsabhängigem Chunking in Blöcke mit variabler Länge aufzuteilen, und hasht die Blöcke dann mithilfe von SHA256. Dadurch wird sichergestellt, dass die meisten Chunk-Hashes für verschiedene Versionen derselben Datei gleich bleiben, selbst wenn der Inhalt um einige Bytes verschoben wird. Die durchschnittliche Blocklänge beträgt ungefähr 64 KB für eine optimale Deduplizierungs- und Komprimierungseffizienz. Wenn die Chunks größer sind, werden sie auch nicht dedupliziert, wenn die Chunks kleiner sind, werden sie nicht so gut komprimiert. Die durchschnittliche Chunk-Länge wird auch für sehr große Dateien erhöht, um zu vermeiden, dass zu viele Chunk-Hashes in den Metadaten vorhanden sind.
8. Wenn die App ein neues JSON-Manifest vom Server empfängt, prüft sie den verfügbaren freien Speicherplatz und erstellt ein neues temporäres Verzeichnis mit einer universell eindeutigen ID. Unter Verwendung seines alten lokalen Manifests als Ausgangspunkt kopiert es dann Blöcke aus lokalen Dateien oder lädt fehlende Blöcke vom Server herunter, um das neue Manifest neu zu erstellen. Nach dem Erstellen der neuen Version überprüft es dann die Verzeichnisstruktur und Signaturen aller Dateiinhalte. Wenn beim Download etwas beschädigt wurde, wird das Update entfernt.
9. Wenn das neue Update erfolgreich mit dem Manifest verifiziert wurde, wird die neue Version der App im neuen Updatepfad gestartet.
10. Die ältere Version bemerkt, dass eine andere Version läuft, und fährt sich herunter.
11. Die neue App wartet darauf, dass die ältere Version heruntergefahren wird, kopiert sich dann selbst in ein anderes temporäres Verzeichnis, benennt die ältere Version in ein Archivverzeichnis um und benennt das temporäre Verzeichnis in den Speicherort der älteren Version (/Applications/Ronomon.app) um. Es läuft dann wieder selbst, aber jetzt vom Speicherort der älteren Version (/Applicatons/Ronomon.app) und räumt dann das Archivverzeichnis auf.
12. Wenn während des Übergangs etwas schief geht, bleibt die ältere Version auf dem kanonischen Pfad, bis sie durch den Umbenennungsaufruf umgeschaltet wird.

Insgesamt funktioniert es in der Produktion sehr gut. Die Deduplizierung und Komprimierung bedeutet, dass nur etwa 33 % für ein typisches Hauptversions-Update heruntergeladen werden müssen und kleinere Updates je nach App nur 1-2 MB benötigen. Das automatische Update behandelt Electron- und App-Code als eine atomare Einheit und verletzt dabei niemals Code-Signaturen.

+1 Zur Idee
+1 Um asar umzubenennen

Ich kam herunter, um diesbezüglich ein Problem zu machen. Ich habe festgestellt, dass dies bereits existiert, also setze ich mein + :100: darauf
Wir brauchen unbedingt eine JRE- oder .NET- oder Adobe Air-ähnliche Lösung, weil das Packen der Laufzeit mit jeder App sie wirklich sperrig macht.

Irgendwelche Updates dazu, eine von den Apps getrennte Laufzeit zu haben?

Ist dies geschlossen, weil eine Lösung entwickelt wurde?

@PierBover Dieses Problem ist offen.

diese - https://github.com/KeitIG/museeks/issues/48 - wurde geschlossen. im Repository eines anderen.

Oh, danke @championswimmer und sorry für die Verwirrung.

Gibt es also Neuigkeiten zur Independent-Laufzeit? Ist das etwas, woran gearbeitet wird?

@PierBover aufgrund der aktuellen Versionsfragmentierung wird es wahrscheinlich nicht so bald passieren (es ist schwer, 2 Elektron-Apps zu finden, die genau dieselbe Version verwenden). Vielleicht nach der Veröffentlichung von v1.

@jorangreef verwenden Sie Ihren differentiellen Update-Mechanismus auf allen Plattformen? Es wäre großartig, wenn Sie diesen Code als eigenständiges Modul veröffentlichen könnten.

@championswimmer Ja , ich habe es geschafft, ein Build-Skript für meine App zu erstellen, also kann ich meine App jetzt verteilen. Aber ich behalte das im Auge, weil es interessant wäre.

@etiktin Ja, das differenzielle automatische Update funktioniert derzeit auf allen Plattformen. Wenn es auch ein minimales Installationsprogramm enthält, das den Download durchführt, könnte das Installationsprogramm von mehreren Apps gemeinsam genutzt werden und eine zwischengespeicherte Version von Electron verwenden, falls bereits verfügbar. Dies würde dazu dienen, Installationen viel schneller zu machen. Ich würde es gerne als Open Source veröffentlichen, wenn die Leute interessiert sind, und werde versuchen, den Code in den nächsten Monaten zu veröffentlichen.

Angenommen, „App 1“ erfordert 0.30.x und kann nicht auf 0.31.x ausgeführt werden, und „App 2“ erfordert das Gegenteil. Wer gewinnt in diesem Szenario?

Dann sollten sie die beiden Versionen installieren und es wird zwei Laufzeiten geben, genau wie VS C++ 2008 mit 2005 koexistiert. Mir gefällt wirklich, wie VS C++-Laufzeiten installiert werden, das Installationsprogramm würde eine erforderliche Version installieren, wenn es keine gibt, und andere können sich darauf verlassen es später, und verschiedene Laufzeiten können koexistieren. Auch die Durchsetzung von Versionsanforderungen scheint im Installer einfacher zu sein.

@louy2 Es gibt einen Unterschied zwischen dem Visual C++-Beispiel (3 Jahre zwischen den Veröffentlichungen) und Electron (mindestens 3 Veröffentlichungen pro Monat).

Ich werde hier mit einem Zitat „Dies ist ein kaputtes System“ witzeln, wenn auch die Mehrheit davon
Die Apps im Electron-Ökosystem sind nicht kompatibel mit +- 0.0.1 oder
0.1.0 Versionsunterschiede

Am 20. Februar 2016 um 18:55 Uhr, Pierre de la Martinière <
[email protected]> schrieb:

@louy2 https://github.com/louy2 Es gibt einen Unterschied zwischen dem
Visual C++-Beispiel (3 Jahre zwischen Veröffentlichungen) und Electron (3 Veröffentlichungen pro
Monat mindestens)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/atom/electron/issues/673#issuecomment -186595285.

+1

Ich habe Elektron mit fpm in ein .deb-Paket gepackt. Dies könnte ein guter Ausgangspunkt für Linux (zumindest Debian- oder RPM-basiert) sein. Sie können hier nachsehen: iamale/electron-deb ; auch eine Beispiel-App ist dabei . (Es funktioniert auch mit asars, es muss nur ein MIME-Eintrag zum Laufzeitpaket hinzugefügt werden.)

Es wäre wirklich toll, wenn wir so etwas auch auf den anderen Plattformen hätten! Ich könnte wahrscheinlich versuchen, es für Windows zu paketieren, aber ich benutze es nicht mehr aktiv und habe nicht wirklich viel Erfahrung damit.

(Danke an @louy2 für den Hinweis auf diesen Thread!)

Übrigens, was ist der MIME-Typ für .asar? Würde application/x-asar genügen?

@iamale Anstelle von fpm hast du dir AppImageKit angesehen. Der Hauptvorteil, den Sie erhalten, besteht darin, dass Sie, anstatt mehrere Bibliotheken und alle zu erstellen, alle Linux-Distributionen mit einer ausführbaren Datei ansprechen können. Sie müssen den Benutzer auch nicht mehr bitten, Abhängigkeiten zu installieren, da diese mit der ausführbaren Datei gebündelt sind. Es ist ein schönes Projekt, bitte werfen Sie einen Blick darauf.

Und was den Pantomimen angeht, wie wäre es mit application/x-electron ?

@steelbrain Das ist eine nette Idee. Dies würde jedoch das ursprüngliche Problem nicht lösen: Die Electron-Laufzeit müsste mit jeder App gepackt werden (weil die Bilder in sich geschlossen sein müssen), und genau darum geht es bei diesem Problem. Obwohl ich denke, dass es relativ einfach sein sollte, AppImages aus Electron-Apps zu erstellen, und ich glaube, dass dies großartig wäre, wenn die traditionelle Paketverwaltung nicht verwendet werden kann (seltene Distributionen oder nicht privilegierte Benutzer). Also danke für den Hinweis!

application/x-electron klingt übrigens super, werde wohl dabei bleiben.

Asar-Unterstützung hinzugefügt! Noch nicht im Repository, werde es heute oder vielleicht morgen neu erstellen. Vorerst erhalten Sie das Paket auf transfer.sh (Link ist für die nächsten 2 Wochen gültig)

Sie benötigen eine asar.json in der .asar-Datei, um Folgendes mitzuteilen:

• empfohlene Version
• kompatible Versionen
  Sobald dies erledigt ist, benötigen Sie eine App, die Elektron (jede Version davon) verwendet, um das Web auf (1) Updates für sich selbst (den Checker) und (2) die vorhandenen Versionen auf Ihrem Computer zu überprüfen. Wenn eine kompatible Version vorhanden ist, wird sie analysiert den Öffnungspfad zur geöffneten .asar-Datei, andernfalls laden Sie die empfohlene Version herunter und prüfen Sie erneut. Die App selbst kann in Electron oder Python geschrieben werden (da sie nur eine minimale oder keine Benutzeroberfläche erfordern würde).

Die Idee ist: Die App, die prüft, ob die benötigte Elektron-Version heruntergeladen wird, hat nichts mit den benötigten Elektron-Versionen zu tun.

Bei Bedarf können Sie den Inhalt von default_app sowie den Rest der App mit Ausnahme davon aktualisieren.

Und dort können Sie die Versionen mit app.setPath("userData", __dirname + "/ElectronVersions"); speichern lassen, dann könnten diese Versionen dort bleiben und neue installiert werden, wenn Bedarf entsteht.

Anstelle von fpm haben Sie sich AppImageKit angesehen .

Es gibt ein AppImage von Atom unter https://bintray.com/probono/AppImages/Atom/_latestVersion#files – einfach herunterladen, chmod a+x , und auf einer nicht allzu veralteten x86_64-Linux-Distribution ausführen.

Das Problem ist nicht nur Linux, wir brauchen einen Weg, es betriebssystemübergreifend zu machen, was bedeutet, dass wir in der Lage sein müssen, es unter Linux, Windows und Mac OSx laufen zu lassen.

Eine Art betriebssystemspezifischer Launcher, der nachschaut, ob die Laufzeit verfügbar und aktuell/kompatibel mit dem Asar-Paket ist

(viele Jahre später) Lassen Sie mich die Diskussion zusammenfassen:

1. @zcbenz schlägt eine Laufzeit vor, die lokale Electron-Instanzen verwaltet, sodass .asar -Pakete nur verteilt und das Bündeln von Electron-Binärdateien vermieden wird. Die Laufzeit verwaltet auch die Ausführung von .asar Paketen.
2. @YurySolovyov schlägt vor, die Manifestdatei mit zusätzlichen Informationen zu erweitern (z. B. erforderliche Electron-Version), damit die Laufzeit weiß, welche Version für welches .asar -Paket verwendet werden soll. Einen Überblick über diesen Ansatz finden Sie hier .
3. @joshuawarner32 stellt die Idee mehrerer Laufzeitversionen, binärer Paketierung (z. B. als .deb ) und automatischer Aktualisierung für .asar -Pakete vor. Darüber hinaus wird die Idee eines Verteilungsservers in Betracht gezogen.
4. @paulcbetts schlägt vor, einen Blick als Steam-Modell zu werfen und etwas Ähnliches zu implementieren. Er weist auf die Komplikationen hin, die mit der Idee einer lokalen Laufzeit verbunden sind, die verschiedene Electron-Versionen usw. unterstützt.
5. [Menschen diskutieren über die Internetgeschwindigkeit in China und ihre Kindheitsangelegenheiten]
6. @hokein weist auf die Komplikationen beim Upgrade der Laufzeit hin. Speziell bzgl. native Module, die erneut für Electron-Header erstellt werden müssen.
7. @etiktin möchte LTS- und Bleeding-Edge-Versionen haben, damit produktionsbereite Apps LTS statt Bleeding Edge verwenden.
8. @Tribex sagt, wenn wir uns an die semantische Versionierung halten, brauchen wir keine lokale Instanz von _allen_ Versionen, sondern nur die, die nicht kompatibel sind.
9. @jorangreef bietet ein Beispiel für ein differenzielles Auto-Update-System, das bereits in der Produktion für seine eigene Anwendung ist.
10. @iamale hat ein fpm-Paket von Electron erstellt, um .asar -Pakete auszuführen.

_Disclaimer: Ich habe versucht, nur die wichtigsten Diskussionspunkte aufzunehmen. Bitte entschuldigen Sie, wenn ich etwas verpasst habe!_

Ich habe die Diskussion bis hierher gelesen, versucht, die wichtigsten Punkte zusammenzufassen und wollte einige davon ansprechen. Die Idee einer Runtime mit „Deep Platform Integrations“ geht über eine einfache lokale Instanz hinaus. Es soll ein Minimum Viable Product definiert werden, das als systemweite Laufzeit fungiert. Ich habe auch eine nette Funktion hinzugefügt, die nützlich sein könnte. Der letzte Abschnitt beschreibt, welche Änderungen/Features implementiert werden müssen.

Begründung:

Was von den meisten Entwicklern gemacht wird (zB das Bündeln von Electron-Binärdateien) ist wie das statische Linken aller gemeinsam genutzten Bibliotheken! Es ist, als würden wir mit jeder Pizza, die wir verkaufen, einen Ofen ausliefern.

MVP:

• Umgebungsmanager : Verfolgt lokal verfügbare Electron-Instanzen. Es kann verwendet werden, um zu entscheiden, welches Paket mit welcher Instanz kompatibel ist (unter Verwendung von erweitertem package.json [siehe unten]). Es sollte sich auch darum kümmern, die richtigen Umgebungsvariablen für auszuführende Pakete zu setzen.
• Update-Manager : Die Möglichkeit der automatischen Aktualisierung (+ Benachrichtigung) und der differenziellen automatischen Aktualisierung wurde diskutiert. Es wäre schön, es als Daemon zu haben, der sich um die Aktualisierung lokaler Instanzen auf die neuesten Versionen kümmert.

Schön zu haben:

• Paket-/Abhängigkeitsmanager : Genau wie apm Atom wird ein Paketmanager benötigt, um .asar -Pakete (von GitHub oder einer bestimmten URL usw.) herunterzuladen und lokal zu installieren (vergleichbar mit apt-get unter Ubuntu oder brew unter Mac).

Anforderungen:

• Erweiterte Manifestdateien : package.json sollte auch einen Semver (oder Semver-Bereich) enthalten, um anzugeben, welche Electron-Version erforderlich ist.
• Definierter Installations-/Deinstallationsvorgang : Das .asar -Paket von ATM enthält alles, was zum Ausführen einer Anwendung erforderlich ist. Es ist jedoch möglich, bei der Installation nur die Quell- und Download-Abhängigkeitsmodule bereitzustellen. Wenn wir zu mutig werden, können wir eine Art _globales_ Verzeichnis haben, das Abhängigkeiten für alle Anwendungen enthält (die flache Struktur von npm 3 könnte helfen). Das kann allerdings sehr schnell sehr kompliziert werden (z. B. beim Deinstallieren einer App).
• Mehrere lokale Laufzeiten : Wenn bisher semantische Versionierung angewendet wurde, gibt es nur zwei inkompatible Versionen 0.x und 1.x . Die Nebenversionen und Patches sollten abwärtskompatibel sein, daher benötigen wir nur die neueste Version von 0.x und 1.x auf dem System.

Inspirationen:

• Umgebungs-/Abhängigkeitsmanager: virtualenv von Python, $#$ rbenv $#$ von Ruby, und siehe auch ruby-build .
• Paketmanager: pip Python, apm von Atom.
• Update-Manager: Der zygote -Prozess von Chromium hat einen interessanten Ansatz für _leise, Hintergrund_-Updates.
• Codeübersetzer (zur Anpassung an neue APIs): Pythons 2to3 .

epm (Elektronenpaketmanager) scheint schon als Name vergeben zu sein...
Nennen Sie vielleicht die Laufzeit elec und die Apps .tron ? Es gibt wahrscheinlich einige Markenprobleme mit TRON, aber es würde cool klingen;)

Vielleicht uepm (Universal Electron Package Manager), da es auf allen Betriebssystemen laufen soll, die von Electron unterstützt werden ... oder epmc (Elektron Package Management Center) und die Datei .epack (Elektronenpaket). Die Erweiterung klingt zumindest besser als .tron und kann nicht mit einem Film verwechselt werden ("Gib mir das Tron-Ding, Alter" _gibt dir den Film_).

Es gibt auch eine Vielzahl von Wörtern im Bereich der theoretischen Physik, die sich auf Elektronen beziehen

• Fermion
• Lepton
• aufladen
• Coulomb
• pauli

Und, nicht direkt verwandt, aber etwas mehr entsprechend dem, was mit einem Paketmanager passiert,

• Boson
  ;)
  (Ich glaube, Photon wurde bereits aufgenommen)

@kapouer +Quark? bin mir aber nicht sicher ob es genommen wird

Quark ist genommen, den Rest weiß ich nicht. Aber warum müssen wir den Status quo beibehalten, wenn diese Vorschlagsliste vorschlägt, den Status quo NICHT beizubehalten? Aber da wir gerade dabei sind, warum nennen wir es nicht Hauldron? Aufgenommen vom LHC. Collider ist keine gute Idee, es gibt dem Produkt einen negativen Schatten, weil seine Bedeutung eng mit Krieg verbunden ist ...

Particle(s) ? Allerdings ziemlich lang.
Partikelliste im Wiki

Obwohl die Benennung wichtig ist, denke ich immer noch, dass wir zuerst die Semantik von Laufzeit/Aktualisierung/Verpackung/Verteilung untersuchen müssen.

lepton scheint perfekt, da es die Teilchenfamilie ist, zu der das Elektron gehört.

Eine etwas außerhalb des Rahmens liegende Idee: Ein generischerer Laufzeitmanager wäre noch großartiger (und nicht wirklich schwieriger zu implementieren). Zum Beispiel könnten wir auch @ nwjs -Binärdateien einschließen und sie auch im selben Versionsmanager-Ding verwalten (genau wie @asdf-vm, aber für GUI-Laufzeiten).

Schnell und schmutzig: https://github.com/iamale/lepton. Unterstützt vorerst nur feste Versionen (semver ist das nächste, was zu tun ist), und Apps sind entpackt (dh noch keine .asar-s).

Hübsch!

+1

Auch wenn kein .asar, @iamale , solange Sie wissen, welche Datei geöffnet werden soll, sollte es meiner Meinung nach in Ordnung sein. Zum Beispiel könnten Sie ein file.something mit json-Code haben, das mit package.json verknüpft ist, damit es weiß, was es öffnen soll ...

Das ist eine ziemlich verrückte Idee, aber wie wäre es mit dem Feld electron in package.json zu machen
jedes (naja, nicht wie irgendein, aber jedes vorbereitete) npm-Paket ausführbar?
Wie:

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

Dies könnte erreicht werden, indem electron die Möglichkeit hinzugefügt wird, npm-Pakete zu installieren und sie für das Hostsystem ausführbar und sichtbar zu machen.
So wie

electron install atom

Damit dies funktioniert, müssten wir electron Befehls- und tatsächliche Laufzeitpakete aufteilen.

aber was ist mit der Umbenennung von package.json in package.electron und einem Inhalt wie diesem?

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

In diesem Beispiel würde es empfehlen, Elektron 1.2 zu verwenden, wenn es nicht gefunden wird, wird auch geprüft, ob es eine Version zwischen 1.2.1 und 1.2.5 gibt, wenn nicht, wird nach 1.3.1 gesucht, dann nach 1.3.0.1, wenn nicht, wird es geprüft für 1.1 und wenn nicht, lädt 1.2 herunter.

Vielleicht könnte es so etwas geben, dass die empfohlene Version automatisch heruntergeladen wird, und wenn dies nicht möglich ist, wird nach kompatiblen Versionen gesucht. Und nehmen Sie alle kompatiblen und überprüfen Sie sie, und wenn keine funktionieren, fragen Sie den Benutzer, ob er keine inkompatible Version verwenden möchte, und wenn er no drückt, wird es mit einer inkompatiblen Version ausgeführt auf dem PC gefunden wird, und wenn keine gefunden wird, statt nach einer inkompatiblen Version zu fragen, ein Fehler-Popup anzeigen, das besagt, dass keine Electron-Installation erkannt wurde.

@sapioit Ein separates Manifest zu haben, klingt für mich nach einer guten Idee. Eine benutzerdefinierte Dateierweiterung würde die Dinge erheblich vereinfachen. (Obwohl .electron etwas lang erscheint.)

Vielleicht laut @iamales Lepton, .lept?

Ich sehe keinen Vorteil darin, package.json nicht zu verwenden, das Elektronenfeld übernimmt den Isolationsteil. Babel und ESlint verwenden diese Technik und machen das ganz gut.
Dies macht es viel einfacher, Apps direkt in/über npm zu veröffentlichen.

Ja, ich unterstütze @YurySolovyov - ich denke, es ist angemessener, es in package.json zu setzen

@YurySolovyov Der Vorteil einer zusätzlichen Datei besteht darin, dass die Laufzeit einen Handler für die Erweiterung der zusätzlichen Datei registrieren und automatisch als Standardöffner der Datei ausführen kann. Um dies mit package.json zu tun, müsste der Handler für jede JSON-Datei registriert werden, was für Benutzer mühsam wäre.

@ Tribex fairer Punkt.
Vielleicht kann package.electron nur eine Art Link sein, der der Laufzeit "Hey, take a look at package.json, it should contain the info on how to launch it" mitteilt. Das war eine "verrückte" Idee, also ja, ich bin damit einverstanden, sie zu optimieren.

Ich stimme @tribex zu, wir brauchen ENTWEDER eine separate Datei oder um die Datei package.json umzubenennen. zu etwas anderem.

@wurysolovoyov das kannst du nicht. Sie können eine Datei nur öffnen, wenn ihr eine Erweiterung angehängt ist. In diesem Fall wird jede Erweiterung mit derselben Software geöffnet. Wenn Sie also nicht damit einverstanden sind, dass Sie .json nicht mit etwas anderem als electron öffnen können (was nur zu einem Fehler führen würde, es sei denn, eine richtige Elektron-App wird geöffnet), können Sie das immer noch tun, aber lassen Sie uns diejenigen, die in der Lage sein möchten, .json -Dateien zu öffnen, in der Lage sein, sie mit dem Programm zu öffnen, mit dem wir sie öffnen möchten.

Andernfalls können Sie die Datei nicht bearbeiten, ohne zuerst den Editor zu öffnen oder jede Minute zu ändern, was .json geöffnet werden soll.

Ich meine @YurySolovyov , nicht @wurysolovoyov

Vielleicht habe ich es nicht klar gesagt: Der Zweck von package.electron besteht nur darin, als Markierung zu dienen, dass dieses Verzeichnis eine App ist, damit die Laufzeit auf package.json verweisen kann, das sich im selben Ordner befindet , und starten Sie eine App. Wenn Sie package.json direkt öffnen, wird es in dem geöffnet, was mit .json in Ihrem Betriebssystem verknüpft ist.

So ähnlich wie ein Shortcut-System.

@YurySolovyov In diesem Fall ist es nur Geschmackssache, ob wir diese Informationen in package.json oder package.electron definieren. Ich persönlich würde es einfach getrennt halten, weil es mir sauberer erscheint. Vielleicht würde die engine-Eigenschaft in package.json aber ausreichen.

@Tribex Es ist auch eine Voraussetzung für die Veröffentlichung von Apps in npm - mit gültigem package.json

@YurySolovyov Richtig. Wenn wir package.electron verwenden, wäre package.json immer noch vorhanden. .electron würde nur verwendet, um Laufzeitinformationen zu definieren, oder im Falle Ihres Vorschlags nur eine Markierung sein.

Im Grunde wäre die package.electron nur als startbarer _Marker_ da, also wäre die package.json noch mit ihren eigenen Daten vorhanden, aber dafür bräuchte man eine separate Datei: _Doppelklick öffnet die App _. Ich möchte immer noch package.electron in my-app.electron oder my-app.electron umbenennen können.

@sapioit sicher, das ist der springende Punkt, wenn Sie eine .electron -Datei haben. Sie können sie benennen, wie Sie möchten, solange sie die Erweiterung .electron hat.

Es erscheint mir immer noch nicht sehr sauber, dass der Runtime-Handler nach *.electron und dann nach package.json suchen muss, um festzustellen, welche Version von electron ausgeführt werden soll, die dann erneut package.json liest.

@Tribex , warum glaubst du, dass package.json zweimal gelesen wird?

• Wenn wir Laufzeitinformationen in die Datei .electron einfügen, würde die Laufzeit die App mit package.json starten, vorausgesetzt, alles ist korrekt und fehlschlägt schnell, wenn dies nicht der Fall ist.
• Wenn wir die Laufzeit direkt in package.json oder unter den Abschnitt electron stellen, würde dies auch nur 1 Lesevorgang erfordern. Auf diese Weise bin ich mir nicht sicher, was ich in die .electron -Datei schreiben soll (Ideen?), ich würde es schaffen, selbst wenn sie leer wäre.

@tribex Das .electron könnte auf das package.json verweisen, nur für den Fall, dass die package.json aus bestimmten Gründen umbenannt wird. Auf diese Weise könnten Sie ein package.json für NPM und ein anderes package.json (vielleicht electron.json ) für das Elektron haben. Warum? Vielleicht möchten Sie, dass Ihre App die Datei „package.json“ enthält, um zu wissen, welche Dinge mit dem Paketmanager importiert werden sollen, aber nach dem Import möchten Sie sie ausführen, ohne Dateien verschieben oder umbenennen zu müssen.

_ app.electron _

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

oder

_ myapp.electron _

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

Oder, wenn wir alles in package.json einfügen, könnten wir den Link .electron only zu .json haben, den wir zum Öffnen der App verwenden möchten, also:

_ app.electron _

{
  "package": "package.json"
}

oder

_ myapp.electron _

{
  "package": "electron.json"
}

Vielleicht möchten Sie auch zwei Launcher im selben Verzeichnis haben, einen für den Client und einen für den Server, wobei der Client die Dateien des Servers verwendet, um einen lokalen Server mit nur einem Player zu starten. Auf diese Weise müssen Sie nicht alle 99 % der Dateien (vorausgesetzt, Sie haben ein Spiel, das mehr als 500 MB an Dateien verwendet) und 5-6 unterschiedliche Dateien duplizieren und sie in zwei separaten Verzeichnissen haben, sondern nur ein zusätzliches Datei, um den Server eigenständig starten zu können. Wörtlich dasselbe wie mehrere ausführbare Dateien im selben Verzeichnis.

Separate package.electron sollten package.electron.json oder etwas mit der Erweiterung .json heißen, damit Editoren und IDE die Syntax richtig bestimmen können.

@StreetStrider Ich würde IDEs lieber beibringen, dass .electron tatsächlich gültig ist .json .
Und das bringt uns auch zu dem Punkt, den wir mit @sapioit über .json Assoziationen diskutiert haben. Ich glaube nicht, dass ein beliebtes Betriebssystem doppelte Erweiterungszuordnungen unterstützt. ( .foo.bar )

Sie können die Erweiterung .json hinzufügen lassen, wenn Sie sie bearbeiten. oder mit der rechten Maustaste klicken und mit einem Editor öffnen, aber genau wie Adobe Air, das die Datei standardmäßig mit ihrem Launcher öffnet, sodass der Benutzer die Datei mit einem Editor öffnen kann, würde das keine Probleme verursachen.

@sapioit Fairer Punkt, ich schätze, ich stimme Ihnen dann zu, wenn es darum geht, auf die Datei package.json zu verweisen.

Für mich sind eine Laufzeit und ein Player zwei verschiedene Dinge. Das kommt jetzt mehr als Spieler rüber. Und es scheint nicht so, als würde es außerhalb einer technisch versierten Community, die an die Konzepte von Paketmanagern gewöhnt ist, weit verbreitet sein.

Das Problem ist, eine Laufzeit zu erstellen. Ähnlich wie JRE und .Net. Kein Spieler.

@baconface Vielleicht könntest du das näher erläutern? Es ist unklar, welche Unterscheidung Sie hier treffen.

@baconface ja, aber sowohl JRE als auch .Net sind ebenfalls installierbar.
Ohne JRE sind .jar -Dateien so nutzlos wie Pakete ohne electron -Laufzeit.

Idealerweise würde dieses Tool mit oder als primäre Methode zur Installation von Elektron vertrieben werden, wodurch das Ausbreitungsproblem idealerweise gemildert würde.

Dazu bräuchten Sie nur ein winziges Tool, um eine ausführbare Datei zu erstellen, die eine bestimmte Datei startet, nämlich die imputierte .electron . So einfach ist das.

.lept sieht toll aus, danke!

Ich persönlich denke, es besteht keine Notwendigkeit, eine neue Konfiguration zu erfinden, pkg.engines sieht für mich hier ziemlich einfach aus (es sollte jedoch einige komplizierte Semver-Ausdrücke zulassen, wie 1.x || >=2.5.0 || 5.0.0 - 7.2.3 aus der Dokumentation von npm , also keine Notwendigkeit für { recommended, compatible, etc } -Strukturen wie in den Beispielen von @sapioit , glaube ich). (Ich habe jedoch ein lepton -Feld hinzugefügt, da scripts.run normalerweise von npm start aufgerufen wird und Lepton die Semantik davon etwas bricht, indem es sein eigenes $VARIABLES hinzufügt .)

Oder, wenn wir alles in package.json einfügen, könnten wir die .electron-only-Verknüpfung zu der .json-Datei haben, die wir zum Öffnen der App verwenden möchten

Scheint mir auch keine gute Idee zu sein. Wenn wir ein Paket mit mehreren Einstiegspunkten haben, könnten wir sie trotzdem alle in einer package.json haben, so als hätten wir jetzt eine scripts -Karte. Ich denke da an sowas:

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

Wenn Sie dies wirklich als ausführbare Dateien haben möchten, können Sie unter Linux / macOS einfache Shell-Skripte verwenden (3 Zeilen einschließlich #!shebang) und unter Windows ... na ja ... ¯_(ツ)_/¯

Zunächst möchten Sie vielleicht einen Blick auf diesen Artikel werfen, der eine bessere Alternative zu semver bietet und dennoch mit so ziemlich allem kompatibel ist: Release.Breaking.Feature.Fix oder warum die semantische Version durch explizite Versionierung ersetzt werden sollte schnellstmöglich

Zweitens stellt sich die Frage, wie man sie tatsächlich unterscheidet. Ich meine, wenn server.js bereits das Argument --debug akzeptiert, warum sollte man sich dann damit beschäftigen und den Leuten nicht erlauben, ihre eigenen Dateikonfigurationen zu haben. Möglicherweise benötigt der Server andere Konfigurationen als der Client, z. B. wenn der Client auf 2.2-2.4 arbeitet und der Server nur auf 1.4-1.9.2.1 ...
Wenn wir das tun, was Sie vorgeschlagen haben, wären wir nur eingeschränkter.

Und was ist mit der Verwendung von mehr Variablen, nicht nur --debug ? Wie soll ich es mit mehr Variablen wie dieser ausführen? Ist es sicher, das zu tun? Wenn ich wollte, dass eine Datei dies tut, hätte ich es schließlich auch mit separaten Dateien tun können, aber auf diese Weise bringt es die möglichen Ergebnisse durcheinander, wenn die .lept -Datei mit Parametern ausgeführt wird.

Wenn ich den Server mit dem Debug-Parameter ausführen wollte, würde ich dann nicht einfach die .lept-Datei mit dem --debug -Argument starten? Oder ich könnte eine andere Datei erstellen, um diese Datei mit dem Argument --debug zu starten. Ist es nicht so einfach?
Ich hoffe ich mache Sinn...

Zunächst möchten Sie vielleicht einen Blick auf diesen Artikel werfen, der eine bessere Alternative zu Semver bietet

Ich finde das ist eine tolle Idee! Ich glaube jedoch nicht, dass Electron zu diesem Versionierungsschema wechseln wird. Ich glaube auch, dass es zwar großartig für Endbenutzerprodukte ist, wir es aber nicht wirklich für Bibliotheken und Engines und Laufzeiten und so brauchen. Idealerweise sollten Benutzer nicht einmal wissen, welche Version von Electron sie verwenden (es sei denn, sie möchten).

Möglicherweise benötigt der Server andere Konfigurationen als der Client

Dies könnte ein Problem sein, aber ich kann mir kein Projekt vorstellen, das mehr als eine Version einer Laufzeitumgebung benötigen würde.

Wenn ich den Server mit dem Debug-Parameter ausführen wollte, würde ich dann nicht einfach die .lept-Datei mit dem Argument --debug starten?

Ja, warum nicht:

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

Diese Dual-Config-package.json eignet sich hervorragend für Fälle, in denen der Server a) viel Codebasis mit dem Client teilt und b) von Endbenutzern ausgeführt werden soll. In anderen Fällen wäre es sinnvoll, alles in zwei Repos/Pakete aufzuteilen, jedes mit seiner eigenen package.json.

Es ist nicht für Electron, sondern für die Projekte, die Sie erstellen. Electron hat wahrscheinlich ein eigenes System, das von der semantischen Versionierung abgeleitet ist, um ihren Bedürfnissen gerecht zu werden, und es ist unwahrscheinlich, dass sie es ändern werden, aber für Lepton und andere Projekte, die noch nicht so weit in _ development hell sind _, könnte es eine gute Idee sein, die semantische Versionierung ganz zu überspringen.

Wenn ich den Server mit dem Debug-Parameter ausführen wollte, würde ich dann nicht einfach die .lept-Datei mit dem Argument --debug starten?

Ja, warum nicht:

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

Nein, ich meine nicht in der Config, sondern über den Launcher. Also das:

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

Aber starten Sie .lept mit dem Argument --myoption=5 , ohne die Dateien zu berühren (außer sie zu öffnen). Da ich mir ziemlich sicher bin, dass Sie das Argument durch den Launcher "_pushen_" können, können Sie auch die Notwendigkeit von --debug entfernen, da Sie es mit dem benutzerdefinierten Argument starten, wenn Sie möchten.

Aber in einer Sache können wir uns meiner Meinung nach einigen: Die Benutzer möchten eine stabile Version haben, für die sie Unterstützung bekommen. Deshalb habe ich " Release " zu einer eigenen Nummer gemacht, denn die Leute werden sich wahrscheinlich nicht viele Nummern merken, aber normalerweise erinnern sie sich an die erste.

@sapioit Wenn das Feld "Release" für Endbenutzer bestimmt ist, wofür sind dann andere? Für den Endbenutzer sollte dies überhaupt keine Rolle spielen, wenn eine neue Version verfügbar ist und eine aktualisierte Laufzeit benötigt wird (über Bump in package.json), dann sollte auch die Laufzeit aktualisiert werden.

Hier sind die Probleme:

1. Benutzer möchten wissen, für welche Version ihnen Support angeboten wird.
2. Sie wollen sich nicht viele _unnütze Zahlen_ merken, wenn sie sich also die Version merken, erinnern sie sich eher an Version 13 als an Version 1.7 (zum Beispiel).
3. Einige Leute möchten nicht aktualisieren, bis bestimmte Dinge passieren, wie zum Beispiel, dass ziemlich viele nVidia-Treiber nicht aktualisiert werden, weil ihre Grafikkarte(n) seit der Hinzufügung der Thunderbolt-Kompatibilität zufällig ausgeworfen werden (je nach Benutzer/Fall , entweder nach dem Hochfahren des Computers, nach dem Öffnen eines Spiels oder ein paar Minuten nach dem Spielen des Spiels). Dies ist ein gutes Beispiel für einen Grund (aber es gibt viele andere, wie die Anzeigen des KMPlayers oder locked on automatische Updates ), die die Benutzer davon abhalten, die neueste Version eines Produkts zu verwenden. Dies erleichtert das Betrachten des Änderungsprotokolls, indem die Komplexität daraus entfernt wird.

Das sind nur einige der Gründe... wenn Sie mehr ins Detail gehen könnten, könnte ich auch mehr ins Detail gehen und Ihnen besser erklären, warum diese Entscheidungen getroffen wurden.

@sapioit Sind Semver-Bereiche wie >= 12.1 nicht flexibel genug, um Unterstützung zu erklären?
Wenn eine neue Laufzeitversion verfügbar ist und diese den Versionsbereich erfüllt, sollten alle nächsten Starts einer App die spätestmögliche Laufzeit verwenden.

Sollten Sie? Aber was ist, wenn sie sich aufgrund technischer Einschränkungen dagegen entscheiden (wie die Sache mit den Anzeigen von KMPlayer und den nVidia-Treibern)?

@sapioit Stellen Sie dann einfach sicher, dass Sie Ihren Laufzeitbereich richtig angegeben haben

@sapioit @YurySolovyov Ist diese Diskussion hier relevant? Ein Laufzeitmanager müsste dem Versionsverwaltungssystem folgen, das Electron verwendet. Ich glaube, eine Diskussion darüber, welches Versionsverwaltungssystem Elektron verwenden _sollte_, gehört in eine andere Ausgabe.

@Tribex etwas. Ich habe versucht zu sagen, dass wir Dinge, die im Grunde bereits gelöst sind, nicht zu kompliziert machen sollten. Aber ich stimme zu, dass der Laufzeitmanager in dieser Hinsicht das Einfachste tun sollte.

@yurysolovyov Warum also nicht einfach so viele Abschnitte in der Versionsnummer zulassen, wie der Spieler möchte?

@sapioit

Es ist nicht für Electron, sondern für die Projekte, die Sie erstellen.

Lepton hat (noch) kein Versionsschema zugewiesen, und Pakete (Apps) können jedes gewünschte Versionsschema verwenden. Wir müssen dies handhaben (z. B. wenn wir das Aktualisieren von Apps über Lepton selbst unterstützen möchten).

Laufzeiten sollten idealerweise semver verwenden, da es sich nicht um Produkte handelt, aber auch hier wird jetzt jede 3-Nummern-Versionierung unterstützt (Entwickler müssten jedoch mit der Angabe von Bereichen vorsichtig sein). Wenn wir jemals mehr als 3 Zahlen unterstützen müssen (wie bei Ihrem Vorschlag zur expliziten Versionierung), müssen wir den Parser erweitern (für Python schlage ich vor, k-bx/python-semver oder podhmo/python-semver zu forken – ersteres kürzlich aktualisiert wurde, während ersteres der node-semver-API enger folgt und das ist, was ich derzeit verwende).

Kann ich nur sagen, dass es einfach eine schlechte Idee ist, einen in Python geschriebenen Runtime-Paketmanager für ein nodejs-Projekt zu haben.
Lass es uns einfach nicht tun. Wie auch immer es heißt, Lepton oder wie auch immer. Schreiben wir es in node oder verwenden Sie etwas anderes. Und lassen Sie uns diese Ausgabe nicht mit unnötigen Mails überfluten, in denen Sie glauben, dass Sie es besser wissen als das gut durchdachte semantische Versionierungsschema

@championswimmer Es wäre interessant, den Laufzeitmanager mit einer darin gepackten Version von Elektron und einer Benutzeroberfläche zu erstellen, die anzeigt, wann andere Versionen heruntergeladen werden.

@championswimmer iamale/lepton ist eine Art Wegwerf-Referenzimplementierung: Ich habe es nur aufgestellt, um verschiedene Ideen zu testen, die in diesem Thread herumschwirren, mehr nicht.

@iamale vielleicht solltest du es in der Readme-Datei angeben, um dann Verwirrung zu vermeiden?

@YurySolovyov Fertig!

Für die eigentliche Implementierung haben wir zwei Möglichkeiten: Entweder verwenden wir node.js oder eine kompilierte Sprache wie C/++ oder Go; und für node müssten wir node.js damit bündeln (oder es vielleicht einfach auf einer der heruntergeladenen Electron-Instanzen ausführen? Wir müssen jedoch sicherstellen, dass es auf _irgendeiner_ vernünftigen Electron-Version läuft).

@iamale Nicht wirklich, wir müssen nur eine standardmäßig installierte Version ausführen. Danach können Updates vor Ort auf eine neuere Version umgestellt werden.

Ich würde mich eher für eine bestimmte Version entscheiden, weil bei Bedarf alles aktualisiert werden kann ...

Lepton ist jetzt vielleicht kein so großer Name, da es sich um ein Bildformat handelt.

Also... wie nennen wir es jetzt? Hadron ?

Quark? Wenn jemand den Namen "Muon" annehmen möchte, kann ich eines meiner Projekte umbenennen.

Ist die Benennung hier nicht eigentlich der unwichtigste Teil?
Haben wir uns auf die Installations-/Aktualisierungs-/Laufzeitsemantik geeinigt?

Warum nicht einfach electron ...

Op 15. Juli. 2016 um 13:22 Uhr Joshua Bemenderfer [email protected] het volgende geschreven:

Quark? Wenn jemand den Namen "Muon" annehmen möchte, kann ich eines meiner Projekte umbenennen.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

@yurisolovyov Ich denke, wir waren uns einig ... mehr oder weniger.
@job-v Das habe ich die ganze Zeit vorgeschlagen. Wählen wir einfach eine aus und bleiben dabei.

@zcbenz beobachtest du diesen Thread?
Wenn ja, wäre es schön, eine Vorstellung davon zu haben, wie dies funktionieren sollte, um hier einige Anweisungen zu erhalten.

Hallo
Irgendwelche Updates zu dieser Elektronen-Laufzeit ?
@zcbenz was denkst du über die ganze Diskussion über:

• Auswählen der Elektron-Version
• Installation der entsprechenden Version
• Bereiten Sie es vor, um in Win, Linux, Mac zu arbeiten
• Welches Tool wird verwendet, um damit zu bauen (Python, Node, Go, C++)?
  @YurySolovyov @sapioit danke für deine tollen Ideen
  @iamale ist Ihre Lösungsarbeit für Debian-basierte Destros 'ubuntu ...'

@alnour-altegani
Ja, es würde für alle dpkg-basierten Distributionen funktionieren, da wir nicht von externen Paketen abhängig sind. RPM-Pakete können auf ähnliche Weise generiert werden, warum nicht?

Ich denke darüber nach, ein zentrales Repo für alle Electron-Dinge zu starten, also könnten Sie Folgendes ausführen:

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 Ich denke, machen Sie Elektron als Deb-Paket und verwenden Sie es als Abhängigkeiten in der Anwendung, die manuell oder aus dem zentralen Repository für viele Deb-Pakete der Elektron-Version installiert werden soll.
und verwenden Sie dann dieses Paket nach der Installation, um die Benutzeranwendung auszuführen

Wenn jemand anfängt, an etwas dafür zu arbeiten, verlinke es vielleicht hier ...

@sapioit Ich habe angefangen, an einer Linux-Lösung (APT/RPM) zu arbeiten. Ein einfacher Dienst, in den Sie .asar hochladen und der in Pakete konvertiert und den Repositories hinzugefügt wird. Sollte auch auf Windows und macOS erweiterbar sein, aber dazu gibt es vorerst keine Versprechungen.

@iamale Cool! Sag Bescheid, wenn es unter Windows funktioniert.

Wie wäre es mit einer Flatpak-Laufzeitumgebung für Linux? Auf diese Weise kann die Laufzeit von mehreren Apps geteilt werden, und Sie erhalten auch Sandboxing.

Da Flatpak seine Abhängigkeit von systemd beseitigt, wird es wahrscheinlich universell für Linux für Upstream-Packaging.

die Laufzeit kann von mehreren Apps geteilt werden

Ich dachte, mit Flatpak wäre das nicht möglich?..

@iamale Flatpak wurde entwickelt, um Laufzeiten gemeinsam zu nutzen – App-Entwickler wählen eine Laufzeit aus, installieren das SDK für diese Laufzeit und erstellen dann eine App mit flatpak-builder oder ähnlichem. Wenn der Benutzer dann die App installiert, installiert Flatpak die zugehörige Laufzeit.

@moosingin3space Danke für die Erklärung! Dann ist es auf jeden Fall eine Überlegung wert.

Die andere Sache, die ich an Flatpak mag, ist, dass es für den Anwendungsfall entwickelt wurde, bei dem ein Benutzer ein Repo hinzufügt, das vom Laufzeit- und App-Entwickler (transparent) ausgeführt wird, und dies automatische Aktualisierungen vornimmt.

Die einzigen Dinge, die ich als Probleme sehen kann, beziehen sich auf die Sicherheit - Systembibliotheken müssen geändert werden, um die "Portal" -Schnittstelle in Flatpak zu verwenden, um ein sicheres Verlassen der Sandbox zu ermöglichen.

Hier scheint an Flatpak gearbeitet zu werden: https://github.com/endlessm/electron-installer-flatpak

Nebenbei bemerkt, Flatpak basiert auf dem OTree- Projekt, das Inhaltsadressierung für Dateisystembäume durchführt. Das bedeutet, dass Dateien mit identischen Prüfsummen automatisch auf der Festplatte dedupliziert werden und dass Aktualisierungen mit statischen Deltas durchgeführt werden. Dies bedeutet, dass nicht nur Electron eine gemeinsame Laufzeit bereitstellen könnte, die unabhängig aktualisiert und von Anwendungen gemeinsam genutzt werden kann, sondern auch, dass Anwendungen, die auf identischen Dateien aufbauen, diese automatisch auf der Festplatte gemeinsam nutzen würden und dass, sobald eine Anwendung und/oder eine Laufzeit installiert ist, aktualisiert wird würde keinen vollständigen Download erfordern.

Verzeihen Sie mir, wenn dies etwas naiv ist, ich frage mich, ob die Möglichkeit in Betracht gezogen wurde, eine Desktop-Umgebung als natürliche logische Weiterentwicklung der Laufzeitumgebung zu erstellen. Die Idee ist, dass es eine Start-App gibt, die Electron beim Start lädt (anstelle von Atom), mit der Möglichkeit, andere Electron-Apps (angesichts der großen wachsenden Bibliothek) zu starten, indem neue Instanzen des Renderers erzeugt oder vielleicht sogar wiederverwendet werden und haben Apps werden in einem neuen Tab geöffnet.

Chrome wie im Betriebssystem scheint meines Erachtens genau dies zu sein (beschränkt sich aber auf Webapps). Desktop-Apps mit vollem fs-Zugriff über nodejs (im Gegensatz zu den Einschränkungen von chromeAPIs) mit Elektron als Laufzeitumgebung auf Linux zu haben (oder sogar die anfängliche explorer.exe in Windows zu ersetzen oder zumindest zu erweitern), wäre meiner Meinung nach sehr aufregend. Ich denke, dies ist eine sauberere Lösung als ChromeOS, das effektiv eine Laufzeit und dann eine Browser-Engine lädt und dann eine App hostet - hier lädt man Apps direkt in der Laufzeit und der Browser selbst ist nur eine weitere App (und es gibt solche viele innovative Elektron-Browser-Projekte in freier Wildbahn).

Auch hier frage ich mich, ob dies in Betracht gezogen wurde oder ob es bereits ein Projekt gibt, das dies tut. Wenn nicht, kann eine Fee dem Github-Management vielleicht ein Wort ins Ohr hauen, um eine Führung zu übernehmen????

PS: Eine Sache, die ich hier nicht vorschlage, ist die Portierung von OS.js (was an sich ein nettes kleines Projekt ist) auf Electron, sondern die Schaffung einer Umgebung für Electron-Apps (obwohl ich einer Wiederverwendung von Code aus OS.js nicht abgeneigt wäre).
PPS: Ich werde ein separates Thema erstellen, wenn es als würdig genug angesehen wird oder wenn es vom Thema einer Laufzeitumgebung ablenkt.

Ich denke, dass eine eingebaute Laufzeitumgebung Electron-Apps viel besser machen würde. Ich denke, das Packen sollte nur das Zippen der Dateien und das Umbenennen der Erweiterung in asar sein, aber dieses Archiv sollte zwei Ordner haben, einen namens asar , mit dem Inhalt des Standard-Laufzeitordners, und einen namens enviroment mit Dateien, die die Standardkonfiguration überschreiben sollten.

Wenn Sie beispielsweise eine neue App ausführen, wird die erforderliche Version von Electron in einen temporären Ordner kopiert und die Laufzeit (Inhalt des Ordners asar ) in den Standardspeicherort für Dateien verschoben, während der optionale Ordner enviroment (mit 3 Unterordnern, windows , linux , macosx ) sollte Dateien enthalten, die über den Standardordner eingefügt werden und dessen Inhalt überschreiben würden.

Auf diese Weise benötigen wir nur eine App oder etwas, um die .asar -Erweiterung einer App zu bewerten, und lassen diese App auf den Ordner mit den heruntergeladenen Versionen von Electron (archiviert) zugreifen und sie in einen temporären Ordner kopieren (extrahieren). , und verwenden Sie den Inhalt von .asar , um die erforderlichen Änderungen vorzunehmen. Führen Sie dann die Electron-Instanz aus diesem temporären Ordner aus und warten Sie, bis sie stirbt, um das Löschen des temporären Ordners zu erzwingen. Für den Anfang wäre es sprunghaft mehr, als wir bereits haben, selbst nur die Standardkonfiguration mit einem Archiv mit einer benutzerdefinierten Erweiterung auf allen unterstützten Betriebssystemen zum Laufen zu bringen. Danach können wir uns Gedanken über einen dritten Ordner machen, config , in dem die aktuellen Konfigurationseinstellungen aufbewahrt werden, und vielleicht einen Ordner _config darin für die Standardkonfigurationseinstellungen (falls wir sie benötigen). ).

Da Chrome-Paket-Apps bald auslaufen, werden die Leute nach Alternativen suchen. Eine Laufzeitumgebung wäre großartig für kleinere Projekte, für die nicht immer Builds/Releases verfügbar sind. Da Apps genau wie Chrome-Apps mit Web-Technologie erstellt werden, wäre es für einen Benutzer wertvoll, die App einfach von der Quelle aus auszuführen. Ich kann es nicht rechtfertigen, unzählige kleinere Projekte auf Electron zu portieren, wenn die einzige Möglichkeit, wie ein Benutzer sie ausführen kann, darin besteht, eine große Binärversion für jedes einzelne Skript oder jede einzelne Anwendung herunterzuladen, und Benutzer können nicht die Vorteile nutzen, den neuesten Commit auszuführen, ohne ihn zu erstellen oder Electron herunterzuladen IDE selbst.

Hallo an alle, auch wenn ich nicht in der JS-zentrierten Welt bin, hatte ich kürzlich eine Idee, die _Electron_ ziemlich ähnlich war (die ich zufällig kannte, aber nicht für die Entwicklung verwende), aber mit einem breiteren Publikum; Um es ganz einfach auszudrücken: _Beschränke die Webtechnologien einfach auf die GUI und stelle APIs bereit._

Machen Sie also weiter mit einer semantisch versionierten gemeinsam genutzten Bibliothek / Laufzeit (die auf _Blink_, _Skia_ usw. aufgebaut ist; vielleicht in – „modern“ – _C++_) und lassen Sie die Entwickler die Sprache auswählen, indem Sie Bindungen verwenden …
zB möchten Sie _JS_, verwenden Sie _Node.JS_; Sie wollen _C++_, kein Problem; Du willst _Python_, mit dem Standard _CPython_ sollte das möglich sein; noch etwas ? vielleicht kann _SWIG_ helfen. In (fast) jedem Fall gewinnen wir.

Sobald wir die gemeinsam genutzte (betriebssystemabhängige) Bibliothek / Laufzeit haben, lösen Sie das Hauptproblem und können den Rest so ausarbeiten, wie Sie es für am besten halten (außer den GUI-Programmieransatz für den Rest von uns zu revolutionieren/modernisieren; a großer Schritt nach vorn!).

Der Ausgangspunkt sollte also der "Split" (sollte sogar einen physikalisch verwandten Namen haben, angesichts der Tatsache, dass Sie sich wirklich darum zu kümmern scheinen) des _Electron_-Projekts sein ... :)

Wir können nicht einmal ein Addon für Electron machen, aber ich denke, das wird nicht so viel Erfolg haben, es sei denn, es wird viel Werbung gemacht.

@dezzeus Es gab zuvor eine Anstrengung in dieser Richtung, die im Sande verlaufen ist. Werfen Sie einen Blick auf die Thrust-Laufzeitumgebung , die den Breach-Browser hosten soll.

Ich habe diesen langen und faszinierenden Thread zweimal durchgelesen, da ich gerne mehr Schwung in diese Richtung sehen würde. Hier ist die letzte Aussage von @zcbenz , die meiner Meinung nach immer noch relevant ist:

Es gibt kein technisches Hindernis bei der Implementierung, das Ganze kann einfach eine Electron-App selbst sein. Aber das Problem ist, dass es auch nicht einfach zu implementieren ist, unter Berücksichtigung aller Details, ich denke _es erfordert ein kleines Team, das Vollzeit daran arbeitet_, ich bin mir nicht sicher, ob es jemals passieren würde.

(Hervorhebung hinzugefügt) – Wie ich das interpretiere, hängt die Lösung, wenn sie jemals gebaut wird, von den Bemühungen der Community und/oder den geschäftlichen Anforderungen von GitHub und anderen Organisationen ab, die daran beteiligt sind.

Eine prägnante Übersicht von @yan-foto sieht nach einem vernünftigen Vorgehensplan aus, mit klaren Zielen/Anforderungen. Es gibt eine Referenzimplementierung/einen Prototyp namens lepton von @iamale , der einen „universellen Runtime-Versionsmanager“ vorschlägt, der auf Electron abzielt. Ein Kommentar von @jorangreef war faszinierend, da er „eine App in Produktion mit einem Semver-Auto-Update-Mechanismus“ mit differentiellem Update, Deduplizierung (nicht sicher, ob diese beiden identisch sind) und Komprimierung beschreibt. Viele der von ihm beschriebenen Merkmale schienen perfekt zum Anpassen/Adoptieren.

Dies sind eindeutige Schritte der Erforschung und des Fortschritts, und ich hoffe, dass aus diesem Prozess produktionswürdige Gesamtlösungen hervorgehen werden.

Es ist schön zu sehen, dass es noch Menschen gibt, die an die Menschheit glauben.

Das einzige, was davon abhält, daraus ein Produkt zu werden, ist der Mangel an unmittelbaren Geschäftsmöglichkeiten, die sich durch die Herstellung dieses Produkts (Konzepts) eröffnen.

@eliot-akira ja, das ist es. Der von mir geschriebene Code führt eine inhaltsbasierte Deduplizierung pro Datei (Blöcke variabler Größe) innerhalb einer Datei durch, um Downloads zu minimieren, wenn sich nur wenige Bytes innerhalb einer Datei ändern. Es aktualisiert auch nur die Dateien, die sich zwischen Versionen ändern, und Aktualisierungen der Anwendung als Ganzes sind angesichts von Fehlern atomar. Entweder wird die neue Version gestartet oder die alte Version bleibt bestehen.

Ich würde den Code gerne als Open Source veröffentlichen, und es gibt einige Dinge, die ich für die Gesamtidee noch codieren müsste. Es wäre großartig, wenn mehrere Electron-Apps einen einzigen Auto-Updater-Supervisor-Prozess gemeinsam nutzen könnten (mit einem lokalen gemeinsam genutzten unveränderlichen Cache für die Deduplizierung über mehrere unabhängige Electron-Apps hinweg).

Das Ziel dieses ganzen Ansatzes wäre es, die gesamte Download-Bandbreite zu minimieren, die zum Installieren und Aktualisieren von Electron-Apps erforderlich ist, während Electron-Apps vollständig voneinander isoliert bleiben (mehrere Apps hätten ihre eigenen Electron-Binärdateien). Ein Nichtziel wäre es, den Speicherplatzbedarf zu minimieren.

Die erste Electron-App-Installation müsste vollständig heruntergeladen werden, aber nachfolgende Electron-App-Installationen würden vom lokalen freigegebenen unveränderlichen Cache profitieren.

Da es zur automatischen Aktualisierung gekommen ist, muss ich das Versionsproblem und die Tatsache einbringen, dass mehrere Versionssysteme anscheinend eine unterschiedliche Anzahl von Ziffern für die Versionierung verwenden. Ich für meinen Teil verwende Explicit Versioning .

Wir haben zwei Arten von Dingen, die hier aktualisiert werden müssen:

• Electron selbst, das Electron Versioning verwendet und
• Apps, für die wir uns nicht wirklich um SemVer oder irgendetwas kümmern müssen, da sie im Allgemeinen keine API haben (es sei denn, sie verwenden vielleicht eine Art Addon-System).

Wenn wir jedoch mehrere Versionierungssysteme unterstützen müssen, könnten wir vielleicht einige Einstellungen in package.json haben, wie "breakingVersionComponents": 1 für semver und 2 für explizite Versionierung oder Electron-Versionierung?

(Eine andere Option wäre, ein weiteres Trennzeichen in Version hinzuzufügen, wie 1.3:3.7 , das brechende und nicht brechende Teile trennen würde. Semver wird dann zu x:y.z und Electron Versioning zu x.y:z . Dies würde zerbrechen jedoch jedes einzelne Werkzeug da draußen, glaube ich.)

@jorangreef Wenn jede App noch über eine eigene Electron-Binärdatei verfügt, würde dies das Problem der übermäßigen RAM-Nutzung nicht beheben, wenn mehrere Electron-Apps geöffnet sind.

Mir ist ein älterer Kommentar von @joshuawarner32 aufgefallen , den ich übersehen hatte. Er erwähnt ein bereits funktionierendes Beispiel, noch keine Allzwecklösung, aber die Zusammenfassung lautet:

- 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

Zusammen mit dem Beispiel von @jorangreef (danke für die weitere Erklärung - Bearbeiten: oh, ich wusste nicht, dass jede App ihre eigene Electron-Binärdatei hat, die ein anderes Modell ist, als ich dachte), sehe ich, dass die Leute bereits ihre bauen eigene spezifische Lösungen für das Problem einer gemeinsam genutzten Laufzeit - die auch Funktionen eines App-Launchers/Managers irgendeiner Art bieten. Es wäre großartig, eine gewisse Konvergenz zu sehen, einige dieser erwähnten Features in Allzweckmodule aufzuteilen.

Ich frage mich, ob es vorhandene, nicht Electron-spezifische Module gibt, die genutzt werden könnten, wie der Download-Mechanismus: Laufzeitserver, Versionierung, differentielle Updates. Es scheint ein bisschen entmutigend, alles von Grund auf neu zu erstellen, wenn andere einige dieser Bereiche bereits "gelöst" haben. @iamale , danke für deine Arbeit an Lepton , das ist in meinen Augen eine konkrete Umsetzung in Richtung einer Lösung.

Eine andere Idee: Veröffentlichen Sie einfach Apps in npm und erstellen Sie einen speziellen npm-Wrapper, der sie installieren und ausführen kann. Es wäre dann wirklich einfach zu implementieren und wahrscheinlich auch einfach zu verwenden (abhängig von der Qualität des Wrappers). Was denkt ihr Leute?

Für oss-Projekte könnten wir npm als Hosting verwenden, für Closed-Source-Projekte müssen wir in der Lage sein, den Paketmanager auf die herunterzuladende .asar-Datei und möglicherweise auf weitere Metadaten zu verweisen. Die Frage ist, wie dieser freundliche Manager aussehen (und heißen) wird.

Außerdem frage ich mich, ob wir wirklich einen separaten Befehl brauchen, um Apps zu installieren, vielleicht nur
electron install atom würde reichen?

Gerade auf Node Weekly gesehen:

Electrino ist eine experimentelle, federleichte Alternative zum beliebten und leistungsstarken Electron. Es implementiert einen winzigen Teil der in Electron verfügbaren APIs, aber die Größe der Ausgabe-App ist viel kleiner.

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

https://github.com/pojala/electrino

@YurySolovyov Closed-Source-Projekte sollten kein Problem damit haben, auch in npm veröffentlicht zu werden – es gibt bereits einige Node.js-Projekte, dh enclose . (Technisch gesehen ist es nicht in npm, nur ein Lader, aber ich kann sowieso nicht sehen, wie das Seitenladen von .asars helfen würde, da sie immer noch entpackt werden können.)

Ich habe nur versucht darüber nachzudenken, wie wir so viel wie möglich vom bestehenden Ökosystem wiederverwenden können.

Ich bin mir nicht sicher, ob wir das wollen ...

@jorangreef Wenn jede App noch über eine eigene Electron-Binärdatei verfügt, würde dies das Problem der übermäßigen RAM-Nutzung nicht beheben, wenn mehrere Electron-Apps geöffnet sind.

@Jop-V Nein, würde es nicht. Ich möchte die Dinge nicht vermischen und mit einem Monster enden. Die Idee ist, einen großartigen Installer/Auto-Updater zu haben, der die meisten Probleme in dem Kommentar löst, der dieses Problem eröffnet hat: https://github.com/electron/electron/issues/673#issue -44580957

Das Problem besteht nicht so sehr darin, mehrere Binärdateien auf der Festplatte zu haben, sondern in der Auswirkung auf das Netzwerk, dass ein Benutzer mehrere Kopien derselben Binärdatei herunterladen und automatisch aktualisieren muss.

Das Lösen der Speichernutzung lohnt sich jedoch auf jeden Fall. Ich denke, es gibt eine Vielzahl von Möglichkeiten, dies zu tun, aber sie müssen nicht unbedingt mit einem deduplizierenden Installer/Auto-Updater gebündelt werden.

Wenn der Speicherplatzbedarf auch ein Problem darstellt, kann dies durch Hardlinks auf Systemen, die dies unterstützen, behoben werden, obwohl dies die Idee der Isolierung zwischen Apps verletzen würde (z. B. wenn eine App beschließt, auf einen Hardlink zu schreiben, der mit etwas anderem geteilt wird).

Alternativ wird APFS zumindest mittelfristig unter macOS Dateien per Referenz kopieren, mit transparenter Deduplizierung unter der Haube, wodurch der Platzbedarf auf der Festplatte minimiert wird. Dies wäre besser als Hardlinks, da es die Isolierung intakt halten würde (Copy-on-Write).

@jorangreef Was bringt es, separate Electron-Binärdateien für Apps zu verwenden? Von welcher Isolation redest du? Sorry, wenn das eine blöde Frage ist, aber ich verstehe es einfach nicht.

@iamale Einige Apps zielen möglicherweise auf verschiedene offizielle Versionen von Electron ab oder verteilen ein vorgefertigtes Electron, das aus modifizierten Quellen kompiliert wurde. Dieser Ansatz würde mit ihnen allen funktionieren. Selbst bei großen Unterschieden bei den Binärdateien (im Gegensatz zu JS- und Asset-Änderungen) würde die Deduplizierung 70 % oder mehr der Downloadanforderungen eliminieren, sodass Apps, die auf unterschiedliche Binärdateien abzielen, immer noch davon profitieren würden.

Mit diesem Ansatz ist es sogar möglich, jede Art von Paket (jeden Satz von Dateien und Verzeichnissen, die durch ein JSON-Manifest definiert sind) zu versenden, nicht unbedingt nur Electron-Apps. Es kann auch eine Python-App sein. Es ist unabhängig von allen Entscheidungen, die der Entwickler treffen möchte, um seine App zu strukturieren oder zu verpacken (Dateien vs. Asar usw.).

Die Hauptidee ist, dass das Ökosystem von sehr kleinen Installations-/Update-Deltas profitiert, da immer mehr Apps denselben Installer/Auto-Updater verwenden. Heutzutage führt jede App ihren eigenen überwachenden Auto-Updater aus und das ist unnötig.

@jorangreef Danke! Ich denke, es ist den klassischen APT/RPM-Repositories sehr ähnlich, nur „intelligenter“ (keine Notwendigkeit, Ihre Abhängigkeiten oder was auch immer zu deklarieren).

Die Frage ist, wie dieser freundliche Manager aussehen (und heißen) wird.

Was ist mit Minifitron (minifiziertes Elektron)?

Ich denke, die Archivdatei (dh .asar ) sollte den Inhalt des Ordners enthalten, in dem sich die Binärdatei von Elektron befindet, damit wir die Dateien hinzufügen oder ersetzen können, die vom Standard abweichen. Wir haben jede Version in einem Ordner oder Archiv und kopieren sie für die Zeit, in der sie ausgeführt wird, in einen neuen temporären Ordner.

Und es sollte eine Option geben, die Apps zu installieren oder zu verkleinern, die Installation würde sie als neue Instanz von Elektron belassen, während die Verkleinerung md5 verwenden würde, um die Dateien zu löschen, die durch das Dearchivieren von .asar nicht geändert wurden

Nur um eine andere Idee einzubringen: Was wäre, wenn jede Electron-App ihre eigenen Kopien von Laufzeiten enthalten würde, aber beim Start könnten sie überprüfen, ob es eine bereits laufende Instanz von Electron (und ihre Version) gibt - wenn sie kompatibel ist (innerhalb von Semver-Bereich). usw.), könnte die App damit kommunizieren und dieselbe Instanz verwenden; wenn nicht kompatibel, kann die App ihre eigene Instanz von Electron starten. Das scheint das Problem der Reduzierung des Speicherbedarfs zu lösen.

(Andererseits, wenn die App gestartet wird, wird es wahrscheinlich sowieso schon mehrere Instanzen der Laufzeit geben ... also vielleicht nicht logisch ...)

@eliot-akira Hatte beim Lesen dieses Threads eine sehr ähnliche Idee.

(Andererseits, wenn die App gestartet wird, wird es wahrscheinlich sowieso schon mehrere Instanzen der Laufzeit geben ... also vielleicht nicht logisch ...)

Nun, es könnte gerade genug laden, um dies zu überprüfen, und nachdem es sieht, dass es keinen verfügbaren "Elektronenpartner" gibt, mit dem es die Laufzeit teilen kann, laden Sie den Rest.

Dies würde jedoch viele Sicherheitsbedenken hervorrufen. Eine bösartige App könnte anderen eine modifizierte Version der Laufzeit anbieten und auf deren Daten zugreifen. Möglicherweise könnte es ein gemeinsam genutztes Speichersegment verwenden, es schreibgeschützt machen, und "Benutzer" -Apps (die die Laufzeit einer zuvor gestarteten App verwenden) könnten die Laufzeit prüfen, aber diese für alle Zielbetriebssysteme zu entwickeln, könnte ein Albtraum sein ( Ich weiß nicht einmal, ob es das in Windows gibt; ich nehme an, es muss).

Wenn nur aus Neugier, ist das unsinnig? Wäre es genauso viel oder viel mehr Arbeit als eine separate gemeinsam genutzte Laufzeitumgebung? Schafft es andere zusätzliche Probleme?

SPÄTER HINZUGEFÜGT: Dies mag weit hergeholt sein, aber es gibt Technologien, um identische Seiten im RAM zu deduplizieren; Sie werden hauptsächlich in Virtualisierungsumgebungen und Hypervisoren verwendet. Das war das erste, woran ich dachte und rannte, um zu überprüfen, ob die heutigen Betriebssysteme dies verwenden, und dann gäbe es vielleicht eine Möglichkeit, Elektron so einzustellen, dass diese Funktion genutzt werden kann, aber anscheinend nicht.

@jorangreef Wenn ein Entwickler die Electron-Binärdatei geändert hat, sollte er dann nicht einfach eine Pull-Anfrage erstellen?

@Jop-V Sie können, aber sie können auch ihre eigene Gabel pflegen. Sie können Quellen sogar nicht veröffentlichen, wenn sie dies nicht wollen – die MIT-Lizenz verpflichtet sie nicht.

@jkurei Um die Idee weiter zu untersuchen, stelle ich mir ein paar Möglichkeiten vor, die funktionieren könnten:

1) Ein dünner nativer Wrapper um Electron oder die App selbst, das wäre der "Launcher". Es sucht nach einer bereits laufenden Instanz von Electron und seiner Version: Wenn kompatibel, übergibt es den Rest des Startvorgangs an diese Instanz und beendet es; Wenn nicht, starten Sie weiterhin eine eigene Instanz von Electron.

2) Eine JavaScript-Bibliothek, die Apps selbst als Launcher in den Hauptprozess importieren könnten. Es könnte ein ähnliches Protokoll wie oben implementieren: Übertragen Sie die Existenz einer Electron-Instanz und eine Möglichkeit für andere Apps (die dieselbe Bibliothek verwenden), sie zu finden und damit zu kommunizieren - vielleicht über einen Netzwerkport ...?

@eliot-akira Ich denke übrigens, dass es bereits eine Art primitives "Protokoll" gibt, von dem du sprichst; Es ist das Ding hinter app.makeSingleInstance , das irgendwie bereits laufende Electron-Prozesse erkennt und ob es sich um dieselbe App handelt oder nicht (wahrscheinlich durch Abrufen des vollständigen ausführbaren Pfads).

@iamale Ich sehe, die Methode verwendet Chromiums native Klasse ProcessSingleton , um das aktuelle App-Verzeichnis zu registrieren (als eindeutige Kennung?). Ja, ich habe mir so etwas vorgestellt, das vor app.on('ready') initialisiert werden soll. Anstatt also nur nach einer vorhandenen Instanz dieser bestimmten App zu suchen, könnte sie nach einer beliebigen Instanz von Electron suchen – und dann „den Startvorgang übergeben“, falls kompatibel.

Für einen anderen Blickwinkel habe ich ein Modul namens node-ipc gefunden, das zwischen separaten Node.js-Prozessen kommunizieren kann. Vielleicht könnte das verwendet werden, um den Startprozess ausschließlich auf JS-Ebene zu verwalten.

Hier ist ein einfaches Beispiel für die gemeinsame Nutzung einer einzelnen Electron-Instanz durch mehrere Apps, wobei node-ipc für die Kommunikation zwischen Prozessen verwendet wird: https://github.com/eliot-akira/singletron-example.

Der IPC-Hub ist ein eigenes Modul , eine dünne Hülle um node-ipc . Die Initialisierung erfolgt im Hauptprozess, main.js ganz unten .

Beim Start versucht die App zunächst, sich mit einer bestehenden Electron-Instanz zu verbinden. Wenn es keine gibt, wird ein "Server" gestartet, der auf Anfragen zwischen Prozessen wartet. Alle nachfolgenden Instanzen der App verbinden sich mit der ersten Instanz, erhalten ihre „Konfiguration“ (Versionen von Chrome, Node, Electron) und können Nachrichten austauschen, um beispielsweise ein neues Fenster für sich selbst anzufordern.

Es ist zunächst eine naive Implementierung, aber was mir an dem Ansatz gefällt, ist, dass es an der App liegt, wie der Server/die Clients verhandeln sollen: Kompatibilität prüfen, neue Fenster öffnen, andere Konfigurationen übergeben usw.

@eliot-akira Ich denke, die Angabe einer Standard-Server-ID ist an dieser Stelle eine _wirklich-wirklich-schlechte_ Idee: Wenn jemand anfängt, dies für seine eigenen Zwecke zu verwenden, wird er wahrscheinlich nur Ihren Beispielcode für seine eigenen Bedürfnisse ändern und das Protokoll brechen ( wodurch andere Apps, die sich darauf verlassen, kaputt gehen).

Ansonsten sieht es gut und sauber aus, danke!

Betreff: Sicherheitsbedenken: Electron-Apps werden bereits mit Benutzerrechten ausgeführt, und wenn wir sie in einem Prozessbaum platzieren, haben sie (oder können) tatsächlich Zugriff auf andere Electron-Instanzen. Ich denke jedoch, wenn wir das abmildern wollen, wird es sicherlich nicht helfen, wenn jeder in der Lage ist, eine gepatchte Electron-Instanz bereitzustellen.

@iamale Vielen Dank für das Feedback. Ich habe die Option zum Festlegen der Server-ID bereitgestellt, falls einige Apps ihr eigenes Protokoll implementieren wollten, anstatt eines gemeinsamen Protokolls für alle Electron-Apps. Tatsächlich gibt es noch kein solches gemeinsames Protokoll - daher ist es zu diesem Zeitpunkt für diesen Zweck nicht praktikabel, dass unbekannte Apps eine Verbindung herstellen und den Startvorgang übergeben. Es sollte ein Proof-of-Concept sein, also werde ich das Dokument aktualisieren, um das zu erwähnen. Ich werde weiter erforschen, wie ich es praktischer machen kann.

Ich denke, es wäre hilfreich für Neuankömmlinge, wieder eine Art Zusammenfassung zu haben, ähnlich der, die jemand vor einem halben Jahr gemacht hat.

Und was macht der Endverbraucher?

Wenn ich der Endbenutzer wäre (und teilweise bin ich ofc), würde ich ein einzelnes .exe/.app/.deb-Paket haben wollen, das ähnlich wie das portableapps.net-Installationsprogramm funktioniert. Diese exe-Datei sollte klein sein und die neueste Upstream-Version der Software automatisch zusammen mit der Runtime herunterladen, wenn sie nicht installiert wurde. In einem einfachen Setup-Prozess sollte ich in der Lage sein, einen "Laufzeitort" (mithilfe des Kontrollkästchens "Erweiterte Optionen") manuell festzulegen, zusammen mit Kontrollkästchen zum Erstellen von Systemverknüpfungen (Desktop, Startmenü usw.).

Wenn ich die nächste Software herunterlade, sollte die vorherige Laufzeit (wie auch immer das aussieht, idc) nach Möglichkeit wiederverwendet werden.

Als Entwickler möchte ich in der Lage sein, ein solches herunterladbares Paket mit (bestenfalls) einem Klick zu erstellen. Dieser eine Klick sollte meinen Code in ein Repository (ähnlich dem Play/Web/App Store) hochladen und ein .exe/.app/.deb-Paket für mich erstellen, das ich mit der Welt teilen kann.

Ich habe noch nicht viel mit Electron zu tun, da ich gerade einen kleinen Mod-Installer mit Electron und Electron-Edge für C# erstelle.

Ich mag naiv sein, aber afaik, der einzige "echte" Grund, warum Dinge nicht mit +-0.1-Versionen kompatibel sind, ist, dass .node-Dateien für jede Version von Electron neu erstellt werden müssen. Könnten diese .node-Dateien nicht während der Einrichtung mit einer Art Cloud-Lösung erstellt werden?

Und wäre es wirklich so eine große Sache, alle halben Jahre oder so einen großen Electron LTS zu erstellen? Ich bezweifle, dass die Entwickler tatsächlich alle bahnbrechenden Funktionen jeder neuen Electron-Veröffentlichung nutzen. Wenn wir sie also (irgendwie) zwingen, länger bei einer Version zu bleiben, würde das die Dinge wirklich viel einfacher machen.

Imo, das einzige Problem ist, keine LTS-Version von Electron zu haben, auf die sich jeder verlassen kann.

Mit dieser LTS-Version sollte das Erstellen von Autoupdates, Deduplizierung, Versionsverwaltung und all diesen anderen Dingen ein Kinderspiel sein.

Die von mir vorgeschlagene Installationslösung hat auch den zusätzlichen Vorteil, dass der Benutzer den Ordner der Software nicht wirklich sieht, sodass wir ihn nicht als .whatever packen und ihm sagen müssen, er solle ihn an einen sicheren Ort verschieben. Außerdem könnten während der Installation mehrere „subexecutables“ hinzugefügt werden (z. B. für Multiplayer-Spiele, mehrere „Profile“ usw.). Diese ausführbaren Dateien sollten einfach somelaunchername.electron heißen, aber im Json-Format mit Informationen darüber, wie die Software gestartet wird (z. B. welche index.html geladen werden soll und ähnliches). node_modules sollten von ausführbaren Dateien gemeinsam genutzt werden (es sei denn, der Entwickler MUSS für jede ausführbare Datei unterschiedliche Versionen eines Moduls verwenden). Dies könnte durch drei node_modules-Ordner erreicht werden. Eine für jede ausführbare Datei und eine für beide. In der package.json würden nur allgemeine Informationen stehen. Jede .electron-Datei sollte (imo) in der Lage sein, die Werte in der package.json zu überschreiben.

Diese .electron-Dateien können dann entweder mit „runtime --appname“ oder einem benutzerdefinierten Protokoll wie Steam dem Startmenü und anderen Speicherorten hinzugefügt werden. Ich bin mir nicht sicher, welcher besser ist, aber der Dampf hat mich in der Vergangenheit schon einige Male angepisst.

Wenn der Entwickler jetzt wirklich eine modifizierte Runtime ausliefern möchte, kann er sie immer noch so packen, wie es derzeit gemacht wird.

Schlussfolgern:
Meiner Meinung nach besteht der nächste Schritt darin, eine stabile LTS-Version zu erstellen und Entwickler mit einer einfachen Paketierungslösung an Bord zu holen. Der Installationsprozess könnte später verbessert werden, derzeit reicht es, eine Runtime und einen Launcher für diese .electron-Dateien herunterzuladen.

Was denkt ihr?

@CiriousJoker Elektron-Builder kann portable App und Web-Installer erstellen. Soweit ich sehe, ist unter Windows eine gemeinsam genutzte DLL eine Lösung. Gemeinsam genutzte DLLs unterstützen auch das Zählen von Referenzen, um ungenutzte Laufzeiten von Elektronen automatisch zu entfernen. Derzeit ist Electron Runtime unter Windows in der One Big Exe (außer node.dll) enthalten. Wenn es in DLLs aufgeteilt werden kann, ist die Lösung auf der Electron-Builder-Seite ziemlich einfach zu implementieren. Es spart auch Speicher, nicht nur Speicherplatz.

@zcbenz @paulcbetts Haben Sie die Verwendung einer gemeinsam genutzten DLL in Betracht gezogen? Ist es möglich, die Größe der exe zu reduzieren und den gesamten Elektronencode in die dll zu verschieben (also nur minimalen Code in der exe zu behalten)? Es ist cool, dass seit Elektron 1.7.5 die gemeinsame C-Laufzeit von node.dll und exe entfernt wird. Jetzt befinden sich bereits 30 MB Code in den DLL-Dateien (aber exe ist immer noch groß – 80 MB), also kann ich anfangen, damit zu experimentieren.

@develar imo, das eigentliche Problem ist nicht, wie wir DLLs teilen können, sondern wie wir eine lts-Version von Elektron bekommen können

Führt Chromium überhaupt Sicherheitsfixes für ältere Versionen durch? Ich habe das starke Gefühl, dass ihre Richtlinie lautet: "Upgrade auf die neueste Version, um sicher zu sein". Ohne Sicherheitsupdates von Chromium scheint ein LTS von Electron in weiter Ferne.

@sedwards2009 Aber gibt es wirklich so viele Bedrohungen? Sicher, ich bin hier vielleicht naiv, aber wir schützen die Benutzer nicht vor dem offenen Internet, sondern vor (meist) lokalen Apps. Das Ausführen einer .exe-Datei ist 10000-mal gefährlicher und das Schreiben von .exe-Viren ist auch 10000-mal einfacher, wenn sogar das Installationsprogramm für meine legitime Elektron-App von AVG als Virus bezeichnet wurde.

Für mich ist es also ausreichend, diese Sicherheit alle 6 Monate oder so zu "erneuern". Außerdem ist es viel unsicherer, jeden Entwickler seine eigene gepackte Version von Chromium verwenden zu lassen, sie könnten damit sowieso viel mehr Böses tun, was wir nicht verhindern können (mit einer gemeinsam genutzten Laufzeitumgebung oder auf andere Weise).

Ja, die Sicherheit endet dort, wo die App rohen Zugriff auf fs und das Netzwerk erhält.
Sie vertrauen entweder dem Anbieter der App oder halten sich fern. <- das ist für Closed-Source-Apps.
Für OSS ist es besser, die meisten von ihnen haben zumindest keine bösen Absichten, können aber Fehler enthalten.

Okay, wie einfach ist es also, eine LTS-Version zu bekommen? Könnten wir nicht einfach die aktuelle Version auswählen und sie als lts-Version deklarieren?

Das größere Problem wird wahrscheinlich später auftauchen, wenn wir versuchen, Entwickler davon zu überzeugen, ihre Apps für diese spezielle Version zu erstellen, aber das ist sowieso der letzte Schritt. Um eine gemeinsame Laufzeit zu erstellen, müssen wir zunächst nur eine Laufzeit auswählen

Ich würde sagen, dies sollte die Entscheidung des Entwicklers sein - um herauszufinden, an welchen Laufzeitversionen die App arbeiten soll.
So ähnlich wie npm Motorenfeld .
Die Aufgabe von Runtime besteht hier darin, die benötigte DLL oder was auch immer abzurufen und die Ausführung der App zu ermöglichen.

Aber wenn wir ihnen erlauben würden, eine von Dutzenden von fast gleichen Laufzeiten auszuwählen, die nicht kompatibel sind, würden wir den Punkt völlig verfehlen, oder? Wir versuchen, mehrere Laufzeiten zu vermeiden und sie nicht nur zu deduplizieren. Wie jemand eingangs erwähnt hat, macht das Deduplizieren von Laufzeiten nicht viel Sinn, wenn eine Chance von 1 zu 20 besteht, dass dieselbe Laufzeit erneut auf demselben System verwendet wird.

Oder meinst du, dass wir den größten Teil der Laufzeit geteilt haben und die verschiedenen Teile einfach nach Bedarf austauschen? Das wäre sinnvoll, aber ich stelle es mir schwer umsetzbar vor

Ich sehe nicht, wie die Laufzeit geteilt werden kann, Hauptverbraucher sind Chromium und Node, die eng integriert sind, und ich bezweifle, dass sie mit mehr als einer Version voneinander funktionieren können.

Ich denke, Knoten hatte so etwas:

• Einige Entwickler wollten die neueste Version 8 und waren damit einverstanden, einen Bruch zu tolerieren
• Große Unternehmen wollten Stabilität und langfristige Unterstützung.

Ich bin mir nicht sicher, ob das Elektron-Team über genügend Ressourcen verfügt, um beide zu unterstützen, aber ich kann mich irren.
Wie auch immer, dies steht nicht im Konflikt mit Versionsbereichen, es muss nur angegeben werden, welche Versionen "LTS" sind.

Nun, wenn jede Elektron-App die gleiche Laufzeit verwendet und nur mit dem .asar-Paket ausgeliefert wird, das speziell für diese Laufzeit erstellt wurde, würden die Dinge funktionieren, oder?

Ja, aber Sie möchten ab und zu neuere Chrome und Node, oder?

Ja, aber ich könnte damit leben, 6 Monate lang denselben Knoten/Chrom zu haben np. Node hat sowieso eine LTS-Version und Chrom ändert sich nicht so sehr von dem, was ich bemerkt habe. Imo, der Vorteil der Einsparung von 100 MB bei jeder App-Installation gleicht die kleinen Geschwindigkeitssteigerungen hin und wieder aus, sobald eine neue Version von Chromium / Electron herauskommt. Sobald wir die Entwickler an Bord haben, sollte es auch nicht zu schwer sein, die Zeit zwischen neuen Versionen der Laufzeitumgebung zu verkürzen. Wir könnten dann die neuste Version der Runtime unterstützen und eine oder vielleicht zwei ältere.

Die .node-Dateien alle 6 Monate neu zu erstellen, sollte meiner Meinung nach auch nicht zu schwierig sein

Electron-Builder wird eine neue Option für alle nsis-Ziele unterstützen — useSharedElectronRuntime. Im Moment werden alle vorhandenen DLLs sein, ich denke, es ist möglich, die Größe der exe zu reduzieren und den Code in die dll zu verschieben, aber es kann später gemacht werden, das Einsparen von 30 MB ist bereits ein gutes Ziel.

1. Erstellen Sie eine signierte Assembly für alle Elektron-DLLs und veröffentlichen Sie sie in GitHub-Releases (Bintray ist keine Option, da nicht zuverlässig).
2. Das Nsis-Installationsprogramm lädt die Assembly herunter und installiert sie, wenn sie noch nicht installiert ist. Sicherheit – Montage ist signiert. Electron-builder unterstützt auch die Installation pro Maschine. Und Windows bietet zusätzliche Sicherheit, wenn die Assembly pro Computer installiert wird, sodass Sie sie bei Bedarf aktivieren können. Eine zusätzliche Option wird in jedem Fall hinzugefügt, um die Baugruppe pro Maschine zu installieren. Noch nicht klar – sollte es standardmäßig wahr oder falsch sein. Ich denke falsch, um sicherzustellen, dass die Elektron-App standardmäßig ohne Admin installiert werden kann.
3. Sie müssen sich keine Gedanken über ungenutzte Elektronenlaufzeit machen – die gemeinsam genutzte DLL unterstützt das Zählen von Referenzen. Bei der App-Deinstallation wird die Assembly entfernt und Windows entfernt sie, wenn keine anderen Apps sie mehr verwenden.

@CiriousJoker Re: Sicherheit. Ich habe nicht an Sicherheitsprobleme gedacht, bei denen die Anwendung selbst bösartig ist. Ich dachte an Elektron-Apps, die nicht vertrauenswürdige Inhalte aussaugen und verwenden. dh jedes Mal, wenn eine Elektron-App eine Webseite aus dem offenen Web in einem webview oder ähnlichem anzeigt.

Viele Apps setzen sich nicht dem offenen Web aus, und sie würden gut auf einem älteren Elektron laufen. Aber das andere Extrem ist so etwas wie Brave, das als Webbrowser nichts anderes tut, als sich selbst zu exponieren. :-)

@sedwards2009 Ja , aber wenn wir anfangen, uns um alle und ihre Mutter zu kümmern, werden wir keine Fortschritte machen. Es wird immer Gründe geben, etwas nicht zu tun. Nicht 100 % der Entwickler an Bord zu bekommen, ist nur ein Opfer, das wir bringen müssen. Wenn sie die Sicherheit wirklich brauchen/wollen, können sie sie manuell haben.

Was die Wahl eines LTS betrifft, so ist die vernünftigste Wahl meiner Meinung nach, uns an Nodejs LTS zu binden, dh welche Version von Electron dem Node LTS entspricht, ist effektiv Electron LTS. Dies könnte etwas Harmonie und Übereinstimmung bringen, so dass wir gemeinsam vorankommen und eine gewisse Sicherheit haben, anstatt es als freie Wahl zu belassen (was diese Gemeinschaft negiert) oder zu streiten (was uns nirgendwo hinführt).

@CxRes Aber welche Version von Electron unterstützen wir? In meinem Projekt bestand das Hauptproblem darin, die .node-Dateien für die spezifische Version von Electron (nicht Node) neu zu erstellen.

Wir könnten einfach die neueste Electron-Version als lts festlegen oder die am weitesten verbreitete verwenden.

Übersehe ich hier etwas? Imo, das Problem ist Electron, nicht Node

Ok, ich versuche es nochmal an einem Beispiel zu erklären:

• Node LTS ist derzeit auf 6.11.1
• Daher wollen wir die höchste Version von Elektron verwenden, die offiziell mit der höchsten Version von Knoten gebaut wurde, die die Bedingung <=6.11.1 >=6.0.0 erfüllt
• Die höchste Version von Elektron, die mit Knoten 6 erstellt wurde, ist Elektron 1.4.15, das mit Knoten 6.5.0 erstellt wurde
• Electron 1.4.15 ist also der Ort, an dem wir für Electron LTS forken und es mit 6.11.1 neu erstellen (und so weiter, bis es neue Node v6-Versionen gibt).

Wenn Node LTS zu v8 wechselt (LTS sind nur gerade Zahlen), werden wir gemeinsam zu einem noch unveröffentlichten Electron migrieren, das mit Node v8 erstellt wird, oder auf der aktuellen LTS-Fork bleiben, bis eine solche Electron-Version veröffentlicht wird.

Was ist mit Entwicklern, die das Neueste und Beste wollen?

@CxRes @CiriousJoker Vermeiden wir hier Off-Topic. Keine technischen Gründe stehen der Verwendung unterschiedlicher Electron-Versionen entgegen. Fragmentierung wird in jedem Fall auftreten (Entwickler hat App vor einem Jahr veröffentlicht und vergessen, andere App eines anderen Entwicklers wurde kürzlich veröffentlicht und verwendet eine andere Version).

@YurySolovyov Die ganze Idee von LTS ist, dass es nicht das Neueste und Beste ist - es ist stabil. Und wenn wir uns nicht darauf einigen können, uns auf eine Lösung zu konzentrieren, sind wir dazu verdammt, unter der Pareto-Suboptimalität zu leiden, keine Laufzeit zu haben, weil keine Gruppe Zeit und Fähigkeit hat, jede Version neu zu erstellen und sie auf Fehler zu überprüfen.

Siehe auch den Kommentar von @CiriousJoker oben:

Ja, aber wenn wir anfangen, uns um alle und ihre Mutter zu kümmern, werden wir keine Fortschritte machen.

@Develar Ok. Aber wie Sie betonen, ist dies kein technisches Problem, sondern ein politisches (sich auf einen Build einigen, der für die meisten Menschen konsistent funktioniert, sodass die Last geteilt wird).

Also was machen wir jetzt? Wählen wir eine lts-Version und fangen an oder versuchen wir, eine Lösung zu finden, damit es für alle funktioniert, indem wir versuchen, eine One-Fits-All-Laufzeit mit modularen DLLs zu erstellen (wie @develar vorschlägt, wenn ich es richtig verstanden habe)

@CiriousJoker Side-by-Side-Montage für eine bestimmte Elektronenversion. zB ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 .

@develar Ich kann dieses Electronruntineassembly-Ding bei Google nicht finden. Könnten Sie einen Link oder etwas bereitstellen?

Imo, um die Dinge zu beschleunigen, sollten wir einfach eine zufällige Electron-Version als LTS-Version auswählen und loslegen. Wir können die Version später trotzdem jederzeit ändern.
@develar Ich weiß immer noch nicht, was du mit dieser Side-by-Side-Montage meinst, aber es muss plattformübergreifend funktionieren, und ich stelle mir vor, wir können es auch später implementieren.

Wir (oder eigentlich ihr Leute) haben jahrelang darüber gesprochen, aber wenn niemand anfängt, wird sich nichts ändern und wir werden weitere 3 Jahre hier sitzen, Ideen diskutieren und Wege finden, nicht anzufangen.

Ich hoffe, dass Elektronenentwickler die Trennung von Laufumgebung und Anwendung so schnell wie möglich lösen können, was Elektronenanwendungen stark fördern wird, und ich werde eine glänzende Zukunft sehen.

Sie haben es seit Jahren nicht gelöst, was mir wie Jahre vorkommt, also bin ich diesbezüglich eher pessimistisch. Sicher, es wäre großartig, aber arbeiten sie überhaupt aktiv daran?

@CiriousJoker Wie oben erwähnt, arbeite ich an der gemeinsamen Laufzeitunterstützung für Elektronen für Windows im Elektron-Builder. Ich habe https://github.com/electron-userland/electron-builder/issues/1942 eingereicht, um den Fortschritt zu verfolgen. Ich hoffe, dass es in 1 Monat einsatzbereit sein wird.

@develar Mein Fehler, muss es übersehen haben. In diesem Fall viel Glück, wäre großartig, wenn Sie es schaffen könnten!

Wenn jemand an der Subdatei content-defined-chunking deduplication interessiert ist, auf die weiter oben im Thread in https://github.com/electron/electron/issues/673#issuecomment -157980607 verwiesen wurde, habe ich sie als Open Source bereitgestellt: https:// github.com/ronomon/deduplication

Dieser lange Thread war in den letzten Monaten inaktiv, aber ich denke, das Problem, das er anspricht, ist es immer noch wert, untersucht zu werden. Während des Wochenendes habe ich ein kleines, minimales einseitiges Dienstprogramm zum Massenumbenennen von Dateien erstellt. Vollgepackt mit Electron-Builder, ist die endgültige Mac-.app-Datei 121 MB groß ...

Ich habe in letzter Zeit über dieses Problem nachgedacht. Dann habe ich auf mein Smartphone geschaut: Die Facebook-App ist 600 MB groß. Chrome ist 325 MB groß, Messenger ist 300 MB groß ... Also eine 120 MB große App auf dem Desktop, das ist mir egal ...

Größe ist heute kein Problem. RAM und Stromverbrauch ist.

_Bearbeiten: Wenn Sie anderer Meinung sind, teilen Sie uns gerne mit, warum_

Für die Windows-Plattform scheinen die Bemühungen von @develar mit dem Elektron-Builder (Elektron-Userland/Elektron-Builder#1942) nahe daran zu sein, eine gemeinsame Laufzeit zu erreichen.

Beachten Sie auch, dass der App-Webkatalog, der Web-Apps als eigenständige Electron-Apps verpackt, das Problem der Verwendung einer gemeinsam genutzten Laufzeitumgebung gelöst hat, um die App-Größe massiv zu reduzieren: webcatalog/webcatalog/issues/171. Dies wurde in ihrem Packager durchgeführt, indem gemeinsam genutzte Ressourcen zwischen Apps symbolisiert wurden.

Progressive Web Applications (PWAs) sind Teillösungen für dieses Problem. Auf Android können Sie PWA zum Startbildschirm hinzufügen und es verhält sich wie eine echte APK. Das Chrome-Team arbeitet jetzt daran, die Installation von PWAs auf dem Desktop zu ermöglichen (http://www.androidpolice.com/2017/12/05/google-wants-progressive-web-apps-replace-chrome-apps/), Microsoft zeigt auch Interesse an der Unterstützung von PWAs (https://www.windowscentral.com/faq-progressive-web-apps-windows-10) und ich hoffe, dass Firefox und Safari bald aufholen werden. Fehlende APIs (z. B. nativer Dateisystemzugriff) werden hinzugefügt, wenn Entwickler Interesse zeigen.
Die meisten webbasierten Electron-Anwendungen können problemlos in PWAs konvertiert werden, aber ich bin mir nicht sicher, was Atom, VSCode betrifft - nativer Code muss wahrscheinlich in WebAssembly neu geschrieben werden.

@develar hat diese Idee Fortschritte gemacht?

Ich werde verwenden, wenn freigegeben!

Nachdem ich kürzlich darauf gestoßen bin, wollte ich nur meine Meinung einbringen. Ich habe jedoch nicht die gesamte Ausgabe gelesen, daher kann es sein, dass ich einige Dinge unwissentlich wiederhole.

Ich denke, dass so etwas sehr wichtig ist, denn obwohl die Größe eines Electron-Programms jetzt nicht so eine große Sache zu sein scheint, sieht man es wirklich, wenn man ein sehr einfaches und kleines Programm verteilt - sagen wir, einen benutzerdefinierten Taschenrechner. In diesem Fall wären etwa 5-10 MB angemessen. 60 MB oder mehr wären jedoch einfach lächerlich. Bei einem größeren Programm wird die Größe von Electron selbst unübersehbarer, aber es kann immer noch lästig sein.

Nun würde ein solcher Laufzeitmodus jedoch eine Art LTS-Release-System erfordern, wenn man die aktuelle Rate von Releases berücksichtigt. Entwickler könnten dann ermutigt werden, sich auf eine LTS-Version zu verlassen, und eine Liste der am häufigsten verwendeten Versionen könnte sogar im Apps-Verzeichnis angezeigt werden, was sie dazu ermutigt, die gängigste zu verwenden, es sei denn, es fehlt eine erforderliche Funktion.

Der Laufzeitmodus selbst sollte meiner Meinung nach auch über ein integriertes System zum Installieren anderer Versionen der Electron-Bibliothek verfügen, sodass das Laufzeitprogramm diese automatisch herunterladen kann, wenn der Benutzer eine Anwendung installieren möchte, die eine andere Version erfordert Schritt innerhalb des Installationsvorgangs.

Ich denke, es sollte auch angemerkt werden, dass die RAM-Auslastung von Electron-Apps damit ebenfalls verbessert werden könnte, obwohl die Änderungen, die zur Umsetzung erforderlich wären, weitaus größer wären. Bei einer gemeinsamen Laufzeit könnten Electron-Apps, die dieselbe Version verwenden, einige Ressourcen im Speicher gemeinsam nutzen.

Wie auch immer, ich bin sowieso sehr neu in der gesamten Quelle des Electron-Projekts, also tut es mir leid, wenn etwas unklar war oder wenn ich etwas unnötig wiederholt habe. Ich hoffe jedoch wirklich, dass dies implementiert wird, da es Electron wirklich zu einer viel vielversprechenderen Plattform für noch mehr Arten von Programmen machen würde. :+1:

@octacian Ich fange an zu glauben, dass PWAs eine bessere Option sind. Allerdings nicht universell – man kann nicht _alles_ mit PWA machen – aber für Dinge wie benutzerdefinierte Taschenrechner sollten sie mehr als genug sein.

Jetzt müssen wir nur noch warten, bis die PWA-Unterstützung auf dem Desktop auftaucht.

Ich denke auch, dass mit einem solchen System 1- es einfacher sein wird, es an eingebettete/kleinere Systeme zu liefern, und 2- in der Zukunft eine elektronenähnliche Betriebssystembasis für mobile Geräte geschaffen werden kann.

@yasinaydin Es gibt bereits LG WebOS. (Es gab früher auch Firefox OS, aber das wird eingestellt)

@KeitIG ​​Mein Herr, Ihr Argument wäre absolut anständig, wenn das einzige Problem mit Electron die Größe wäre. Ein etwas größeres Programm zu haben, aber die Komplexität und die Möglichkeit des Scheiterns für Entwickler zu vereinfachen (wir können nicht leugnen, dass Electron großartig darin ist, Entwicklern eine standardisierte Methode zum Erstellen von Apps ohne viel Platz zum Vermasseln zu bieten), wäre großartig. Leider bedeutet die Verwendung einer separaten Version der Bibliotheken für jede App auch eine erhöhte RAM-Nutzung und verteilte (und schwieriger zu behebende) Sicherheitsprobleme. Ich hatte dies in meinem doppelten Problem besser erklärt, aber kurz gesagt, ich denke wirklich, dass eine gemeinsam genutzte Laufzeitbibliothek, die Sie selbst aktualisieren und zwischen verschiedenen Electron-Apps teilen können (die auch in einer "Lite" -Version ausgeliefert würden, so ähnlich wie wann Einige Entwickler haben früher Java-Dateien zur Verwendung auf Ihrer JVM verteilt und gebündelte .exe s) wäre wirklich der Deal Breaker für Electron, und obwohl ich verstehe, dass es wahrscheinlich eine Menge Arbeit wäre, macht es mich traurig dass es noch nicht in den Plänen der Entwickler ist. Hoffen wir, dass sie es in Zukunft tun.

@dre-hh Obwohl ich die gute Absicht Ihres Vorschlags anerkenne, ist er unter anderem zu restriktiv. Beispielsweise habe ich für meinen Arbeitgeber eine kommerzielle Elektron-App entwickelt, die in stark regulierten Umgebungen verwendet wird (keine Internetverbindung, Anforderungen an die Rückverfolgbarkeit / Auditierung usw.). Unsere Kunden können uns nicht erlauben, die Software automatisch zu aktualisieren. Es ist eine ganz andere Welt als typische Web-Apps für die Masse. Evergreen-Browser und die automatische Installation von Betriebssystem-Sicherheitsupdates sind meiner Meinung nach in den meisten Fällen eine großartige Idee für die meisten Menschen, aber mein Punkt ist, dass sie nicht überall passen. Manchmal ist das Risiko einer durch Softwareänderungen verursachten Unterbrechung weitaus größer als das Risiko, das mit der Ausführung einer veralteten Softwareversion verbunden ist, insbesondere in kontrollierten Umgebungen, in denen andere Sicherheitsminderungstechniken vorhanden sind. Daher ist eine extreme Maßnahme wie das Blockieren der Ausführung von Anwendungen mit veralteten Versionen von Electron (oder wirklich jeder Bibliothek) keine ideale Lösung, wenn überhaupt eine Lösung. (Außerdem haben Administratoren bereits viele Steuerelemente, um einzuschränken, welche Programme ausgeführt werden können, sodass sie dies ohne neue Betriebssystemfunktionen implementieren könnten.)

Darüber hinaus, wie bei den meisten Sicherheitsbedenken, stammt ein Großteil des Problems von Entwicklern, die sich entweder der Risiken nicht bewusst sind oder sich aus irgendeinem Grund (z. B. aus Zeitmangel) entschieden haben, die Sicherheitsrichtlinien für die von ihnen verwendeten Tools nicht zu befolgen. (z. B. Sicherheit, native Fähigkeiten und Ihre Verantwortung ) Wir als Entwickler müssen alle unseren Teil dazu beitragen, Verantwortung für die Qualität (einschließlich Sicherheit) unserer Arbeit zu übernehmen.

Schließlich halte ich es für einen Fehler, sich an ein kommerzielles Softwareunternehmen wie Microsoft zu wenden, um diese Bedenken auszuräumen. Dies liegt zum Teil daran, dass wir, wie bereits erwähnt, nicht erwarten können, sichere Anwendungen von Entwicklern zu erstellen, die nicht sicherheitsbewusst sind. Noch wichtiger, zumindest meiner Meinung nach, ist, dass eines der schönen Dinge an Electron seine Open-Source- und Multi-Plattform-Natur ist, die für kommerzielle Softwareanbieter normalerweise keine hohe Priorität haben. Gut durchdachte und erfolgreiche Fortschritte erfordern höchstwahrscheinlich ein gewisses Maß an Konsens und Bemühungen der gesamten Entwicklergemeinschaft. Natürlich werden Beiträge von kommerziellen Unternehmen natürlich geschätzt.

@jacobq Falls Sie es nicht wussten, Microsoft ist der Eigentümer von Electron.

Falls Sie es nicht wussten, Microsoft ist der Eigentümer von Electron.

@Jop-V Bitte fügen Sie ein Zitat dafür hinzu; Ich glaube nicht, dass das richtig ist. Auf der Startseite von electronjs.com heißt es:

Electron ist ein Open-Source-Projekt, das von GitHub und einer aktiven Community von Mitwirkenden gepflegt wird.

Microsoft ist ein Verbraucher von Electron (verwendet es in Produkten wie Visual Studio Code) und (ich nehme an) auch ein Mitwirkender, aber sie haben kein Eigentum. Die Lizenzdatei erwähnt weder Microsoft, noch deutet der Wikipedia-Artikel darauf hin, dass sie eine Eigentumsposition haben.

@jacobq Microsoft wird GitHub erwerben. Wenn also Electron derzeit von GitHub verwaltet wird, wird es, soweit ich das beurteilen kann, bald von Microsoft verwaltet.

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

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

Die Übernahme von Github durch Microsoft bedeutet für Electron nichts. Github ist/bleibt ein separates Unternehmen mit eigenen Produkten und Projekten. Ich sehe nicht, dass Microsoft den Besitz von Electron übernimmt, genauso wenig wie ich sehe, dass Microsoft den Besitz von Atom übernimmt.

Ich denke jedoch, dass diese Debatte dem Ausgangspunkt des Problems nicht wirklich weiterhilft.

https://github.com/GoogleChromeLabs/carlo

Carlo sieht ziemlich faszinierend aus. Ich habe es ausprobiert und es ist sehr intuitiv. Hat schon jemand damit experimentiert?

Warum werden all die Vorschläge zur Verringerung der Aufblähung der Festplatte und des Arbeitsspeichers der Endbenutzer nie bearbeitet? Dies ist eine fantastische Idee, die 4 Jahre alt ist und immer noch nur eine Idee ist. Ich kann nicht verstehen, warum solche Dinge nicht ganz oben auf der Prioritätenliste des Projekts stehen

@danielo515 , denn anstatt ein weiteres fleißiges Projekt zu erstellen, gibt es https://github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app

Worüber redest du? Das ist schon ein riesiges Projekt. Es ist auch das am weitesten verbreitete und am weitesten verbreitete, daher erscheint es mir nicht richtig, Leute auf ein anderes Projekt für ein Feature hinzuweisen, das Teil dieses sein sollte.
Außerdem, Carlo, ist es ein anderer Ansatz, sie verwenden Ihr installiertes Chrome, also ist es nicht wie eine Daemon-Version von Electron.

Ich kann nicht verstehen, warum solche Dinge nicht ganz oben auf der Prioritätenliste des Projekts stehen

Weil es schwer ist, es Wirklichkeit werden zu lassen (wie „wirklich“ schwer).

Wenn Sie nicht zufrieden sind (was völlig verständlich ist), zögern Sie nicht, Electron zu forken und eine PR einzureichen.

Verstehen Sie mich nicht falsch, wenn es eine einfache Lösung für dieses Problem gäbe, wäre sie sicher bereits implementiert worden.

@ Danielo515

... Leute auf ein anderes Projekt für ein Feature zu verweisen, das Teil dieses sein sollte, scheint mir nicht richtig zu sein.

Ich denke, der Punkt ist, dass jedes Projekt seine Stärken und Schwächen hat, und Carlo eignet sich gut für Fälle mit begrenztem Platzangebot. Für meine Anwendungsfälle ist eine App-Größe von 100 MB vollkommen in Ordnung. Obwohl ich dieses Feature gerne sehen würde, sind mir die anderen Elektron-Features weitaus wichtiger.

@jacobq Ja, du hast Recht – verschiedene Anwendungsfälle erfordern verschiedene Tools.

Falls es noch jemanden interessiert, ich habe eine Liste ähnlicher Tools zum Entwickeln von js-Apps auf dem Desktop erstellt.

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

Ich benutze Electron einfach nicht, weil ich es mir nicht leisten kann, Dutzende von 100-MB-Apps zu aktualisieren - und Sie wissen, wie Apps aktualisiert werden müssen (ich habe andere Meinungen dazu, aber das Teilen hilft nicht).
Was mir am Ansatz von Carlo sehr gefällt, ist die Idee, den installierten Browser zu verwenden.
Noch besser, Carlo könnte sicherlich jeden verfügbaren Browser verwenden, nicht nur Chromium, da Puppeteer auch andere Browser verwalten kann. Unter OSX würden Sie Safari spawnen, unter Linux Epiphany (Webkitgtk) oder Firefox usw.
Um also wirklich eine App zu erhalten, müssten Sie nur nodejs und Ihre App installieren.
Nun stellt sich die Frage: Wie gut kann pkg bei der Verwendung von systeminstallierten Libs und nativen Addons sein?
Wenn ich zum Beispiel die App, die ich gerade entwickle, paketieren müsste, bräuchte ich postgresql, sharp (und vips), webkitgtk und exiftool. Ich möchte die App nur an Benutzer von Linux Debian, Fedora oder Ubuntu verteilen können. Ich würde gerne mit den "verrückten Bündeln" davonkommen und stattdessen kostenlos von der harten Arbeit dieser Distributionen profitieren.

@kapouer ... verwende den installierten Browser ...

Obwohl es theoretisch eine gute Idee ist, führt dies zu erhöhten Schwierigkeiten beim Codieren von Anwendungen auf der Webseite, da Sie sich jetzt auf die Unterstützung mehrerer Browser konzentrieren müssten und die Browser, auf die sie zurückgreifen, möglicherweise in dem, was Sie tun möchten, eingeschränkt sind haben keine volle Unterstützung für Dinge, wie Sie sie in Chromium finden können. Sie verlassen sich auch darauf, dass der Benutzer sicherstellt, dass sein Browser auf dem neuesten Stand ist und dass die verschiedenen Browseranbieter Ihre Anwendung nicht mit einem Update beschädigen.

Viele Benutzer haben massive 50-MB-Updates umgangen, indem sie auf Delta-Updates umgestiegen sind oder Paketmanager nur die .asar-Datei oder Ressourcenordner aktualisieren lassen. Und führen Sie nur bei Bedarf ein großes Electron-Update durch. So machen wir es in unserem Unternehmen und es hat super geklappt.

Aus der Sicht eines naiven Benutzers würde die Verwendung der Electron-App-Shell als Shared Runtime die Verteilung und Verwendung wirklich einfach machen. Für zB. Mit 5 Elektron-Apps in einem einzigen System haben Sie 5 Instanzen von App-Shell und es sind ungefähr 300 MB groß, richtig?

Ich bin fest davon überzeugt, dass Electron die Zukunft von Desktop UX ist, und dies wäre ein großer Schritt (sehen Sie sich .NET Runtime an – vielleicht ein schlechter Vergleich, aber es ist cool, oder? ), um die Web-Technologie leistungsfähiger zu machen.

Electron hat bereits eine Laufzeitumgebung für Entwicklungszwecke, nicht wahr? Das „Elektron“. Befehl, meine ich. Warum nicht das für die Benutzerseite wiederverwenden?

Um mit mehreren Apps in Abhängigkeit von verschiedenen Electron-Versionen umzugehen, können Sie den Ansatz verwenden, den .NET Core verwendet. Installieren Sie einfach mehrere Versionen der Laufzeitumgebung nebeneinander, und lassen Sie Apps die minimale (oder maximale) Version deklarieren, die sie benötigen.

Ich habe einen Proof-of-Concept-Launcher erstellt: https://github.com/ProPuke/electron-shared

Einzelne ausführbare Datei mit einer Größe von weniger als 1 MB. Übergeben Sie ihm ein App-Verzeichnis oder ein Asar-Paket und es überprüft Ihre Anforderungen an die Electron-Version in Ihren Paket.json-DevDependencies und lädt/führt mit der richtigen Version aus.

Electron-Laufzeiten werden in AppData\Local\Local\electron-shared (Windows) .cache/electron-shared (Linux) Library/Application Support/electron-shared (Mac) gespeichert, damit sie zwischen Apps geteilt werden können.

Ohne Angabe eines Pfads wird automatisch das Verzeichnis app oder app.asar ausgeführt, falls eines vorhanden ist. Sie könnten Ihre App also nur mit dieser Datei und app.asar verteilen. Oder dies könnte mit .asar-Dateien verknüpft werden und nur die asars könnten verteilt werden.

Es hat auch ein paar Befehlszeilenparameter, einschließlich --downloadOnly und --silent , sodass es während des Setup-Prozesses von Installern aufgerufen werden kann.

Es behandelt keine automatischen Updates (es wird nur heruntergeladen, wenn eine kompatible Version von Electron nicht bereits auf Ihrem Computer verfügbar ist), aber dies könnte regelmäßig beim Start oder durch einen Hintergrunddienst erfolgen (solange die Laufzeiten in der richtige Ort, an dem es die neuesten Apps findet und verwendet, wenn Apps gestartet werden).

Zu wissen, wann alte Kopien der Laufzeiten gelöscht werden müssen, kann schwierig sein. Sie könnten sich mit der Zeit anhäufen. Wir müssten entweder nachverfolgen, welche installierten Apps welche Versionen verwendet haben (und somit nicht mehr benötigt wurden) oder vielleicht nur ein letztes Verwendungsdatum für jede Laufzeitversion speichern und sie automatisch löschen, wenn sie nicht verwendet wurden in einer Weile.

Wie auch immer, ein Proof of Concept / Vorschlag. Löst so etwas Probleme? Habe ich irgendetwas Auffälliges und Offensichtliches übersehen?

Ich habe Electron-Shared von @ProPuke ausprobiert und konnte die Electron-Quick-Start- Demo ausführen. Aber ich konnte keine der auf der electronjs -Website beschriebenen Apps ausführen (weil die meisten Apps ein Shell-Skript verwenden, um die App zu starten, und nicht nur package.json, wie ich verstehe). Aber ich glaube, dieser _Proof of Concept/Proposal_ könnte ein Hinweis auf das nächste große Upgrade sein.

Ich habe eine Idee. Elektron Weil unterstützt derzeit den Befehl "electron.exe Pfad". Ich denke, Sie können es öffnen, indem Sie mehrere Asars von der Befehlszeile aus aufrufen. Derzeit habe ich nur eine Idee. Ich hoffe, jemand kann es tun, weil ich diese Software gerade angesprochen habe.
_____________ chinesische Übersetzungsversion__________
Ich habe eine Idee. Denn aktuell unterstützt Electron den Befehl „electron.exe path“. Ich denke, es kann geöffnet werden, indem Sie die Befehlszeile verwenden, um mehrere Asars aufzurufen. Ich habe im Moment nur eine Idee, ich hoffe, jemand kann sich das ansehen, weil ich mich gerade mit dieser Software beschäftigt habe.

Nach einem flüchtigen Blick auf die gesamte Konversation (und andere Diskussionen wie mehrere "Apps") fasse ich zusammen - das Aufrufen mehrerer asars nativ, anstatt mit mehreren Binärdateien zu beginnen, hat eine lange Geschichte, wird aber nicht unterstützt. Aber Electrons default_app wird über die Befehlszeile implementiert (vielleicht weiß ich es vorerst nicht). Ich denke, dass das Aufrufen von cmd durch Elektron (es scheint möglich zu sein) in der Lage sein sollte, diese Funktionskompatibilität zu erreichen.
Bei einem flüchtigen Blick auf alle Konversationen (und andere Diskussionen, wie z. B. mehrere "Apps"), komme ich zu dem Schluss, dass native Aufrufe an mehrere Asar anstelle mehrerer Binärdateien beginnen, was eine lange Geschichte hat, aber nicht unterstützt wird. Electron's default_app ist es jedoch eine Implementierung, die die Befehlszeile nutzt (und vielleicht weiß ich es eine Weile nicht).Ich möchte cmd über Elektron aufrufen (als ob ich könnte) sollte in der Lage sein, diese Funktionskompatibilitätsleiste zu erreichen.

Im schlimmsten Fall müssten Sie eine .bat-Datei oder das Äquivalent für Nicht-Windows-Betriebssysteme erstellen und sie von Electron ausführen.

Möglicherweise nützliche Links:

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

Es scheint, dass nur dann, wenn es keinen app.asar- oder App-Ordner gibt, der Befehl electron. exe-Pfad gültig

Oh, also brauchen Sie ein Elektron, um den Exe-Pfad innerhalb des Elektrons auszuführen, das verwendet wird, um all das einzurichten. Immer noch besser als eine Elektroinstallation für jede einzelne verwendete App. Sie benötigen nur eine Elektron-Installation für jede Elektron-Version, die Ihre App benötigt. Sie müssten wahrscheinlich eine separate Erweiterung erstellen, bei der es sich um ein umbenanntes Zip-Archiv handelt, das sowohl die App enthält, die wir auszuführen versuchen, als auch eine Datei mit der empfohlenen Version (würde sie sofort ausführen), kompatiblen Versionen (würde fragen, ob ausgeführt werden soll oder die empfohlene Version installieren und auch die empfohlene Electron-Version im Hintergrund herunterladen) oder nur einen Download-Fortschrittsbalken anzeigen, damit die empfohlene Version heruntergeladen wird.

Oder ich habe etwas falsch verstanden.

Diese Idee ist wahrscheinlich die gleiche: Da Fledermaus derzeit einfach zu sagen ist, nehmen Sie es zum Beispiel, der Inhalt ist Elektron.exe App1.asar, nach der Ausführung öffnet Elektron den Inhalt von App1.asar. So funktioniert es wahrscheinlich, aber wenn Sie den nächsten Satz, electron.exe app2.asar, in bat schreiben, können Sie dies nur tun, wenn das Elektron von app1.asar endet. Und wenn die Fledermaus ausgeschaltet wird, wird das Elektron ausgeschaltet. Aber ich schreibe „electron.exe app3.asar|electron.exe-v“ oder „electron.exe app3.asar|start“ und so weiter. Wenn ich Fledermaus schließe, kann Elektron überleben, aber ich kann nicht weiter andere Asars öffnen. Ich denke, dieses eigenständige Programm könnte besser sein als dieses, weil bat immer noch etwas eingeschränkt ist.

Nicht, wenn Sie temporäre Ordner verwenden.

Sie haben die (archivierten oder nicht archivierten) Versionen in einem Electron_versions-Ordner, von dem Sie entweder die empfohlene Version oder die neueste kompatible Version verwenden, die Sie heruntergeladen haben, indem Sie die Version, die Sie verwenden, in einen temporären Ordner kopieren, und nachdem Sie sie fertiggestellt haben, Sie den Ordner löschen.

Der Pfad der lokal gespeicherten Dateien befindet sich entweder im Elektron-Ordner oder neben der von Ihnen verwendeten Datei. Wenn Sie es aus einem Archiv verwenden, das die Dinge enthält, die ich innerhalb der letzten 24 Stunden erwähnt habe, müssen Sie die gespeicherten Datendateien zurück in das Archiv verschieben oder sie überhaupt nicht verschieben, bevor Sie diesen temporären Elektron-Instanzordner löschen.

SSD？

???

Der Grund für das Löschen des temporären Elektron-Ordners liegt darin, dass die App theoretisch die Dateien der Elektron-Installation ändern könnte, auf der sie ausgeführt werden, und zwar beabsichtigt. Das heißt, das Archiv kann die Dateien und Ordner enthalten, die innerhalb der temporären Elektron-Installation geschrieben oder überschrieben werden müssen.

Nachdem die Installation verwendet wurde, kann sie von der ausgeführten App als beschädigt behandelt werden, sodass sie nicht recycelt werden kann und daher gelöscht werden muss. Die Version, von der die bis dahin beschädigte Installation als Basis verwendet wurde, ist jedoch immer noch intakt, im Ordner electron_versions der runtime-electron-App, die wir zu erstellen versuchen.

Wenn das zuvor erwähnte Archiv mit eindeutiger Erweiterung schreibgeschützt ist, könnten die verwendeten Daten theoretisch nach %appdata% verschoben werden. Eine App, die innerhalb des Laufzeitmodus-Elektrons läuft, das wir zu erstellen versuchen, wäre also tatsächlich portabel (in sich geschlossen), und daher würde das Kopieren dieser Datei ausreichen, um die Konfiguration dieser App mitzunehmen.

Aber wir müssten wahrscheinlich auch eine Update-Funktion für diesen Dateityp hinzufügen, was eine weitere Elektron-Installation wäre, die die Dateien aus der neuen Installationsdatei in eine Kopie der alten Installationsdatei kopieren und überschreiben würde, und die neue Installationsdatei mit der zurückgeben würde Daten, die es hatte. Das Ganze könnte automatisch erledigt werden, wenn es einen Download-Link in den Dateien gibt, die von dem Runtime-Mode-Elektron verwendet werden, das wir zu erstellen versuchen.

Sobald dies fertig ist, können Sie, wenn Sie noch einen Schritt weiter gehen möchten, sogar einen Git-Client hinzufügen, von dem aus Sie die Apps aktualisieren können, obwohl dies möglicherweise die Verwendung von Github und Bitbucket erfordert, um kompilierte Archivdateien zu hosten.

Sie können die Download-Datei „curl, wget, aria2c“ verwenden, und der Benutzer muss kein git installieren.

Ich mache ein Tool electron-runtime das ähnlich wie electron-builder funktioniert. Es bündelt nur die app.asar -Datei mit einem einfachen sh -Skript (später wird dies eine Benutzeroberfläche sein, um den Fortschritt des Electron-Downloads anzuzeigen). Derzeit funktioniert es nur für macOS.

Wenn eine mit electron-runtime gepackte App ausgeführt wird, lädt sie grundsätzlich eine entsprechende Hauptversion von Electron herunter, aber die neueste im Falle von Nebenversionen und Patches, da die Breaking Changes von Electron nur in Hauptversionsinkrementen auftreten.

Die electron-quick-start App ist nur 62 KB groß, Screenshot:

Wenn Sie daran interessiert sind, hinterlassen Sie einen Stern, eine PR oder ein Problem.

Ich habe das Paket ein wenig aktualisiert, sodass es mit electron-builder gebaut werden kann ( hier wird beschrieben, wie es funktioniert ). Jetzt können Sie sogar Visual Studio Code damit erstellen! (aber immer noch nur auf macOS).

Ich habe erfolgreich eine erste Version von electron-global veröffentlicht! (Ich habe es geändert, da electron-runtime vergeben ist). Sie können Ihre App mit meinem npm-Paket mit electron-builder erstellen. Ich habe auch eine Benutzeroberfläche mit einem Fortschrittsbalken hinzugefügt, um den Fortschritt eines Elektron-Downloads anzuzeigen. Ich hoffe, es wird populärer, um Electron besser zu machen.

Es tut mir leid, ich benutze das Windows-System und habe nicht das Geld, um das MacOS zu verwenden. Aber ich glaube, dass Ihr Projekt sehr erfolgreich sein wird.

@nwdxlgzs Es unterstützt Windows, macOS und Linux...

Ich dachte, dieses Projekt unterstützt nur MAC.
Ich werde mir Zeit nehmen, um dieses großartige Projekt auszuprobieren.

Danke, dass du es geschafft hast und uns auf dem Laufenden hältst!
Ich benutze auch Windows.
Ich schaue mir den Code an, wenn ich die Änderung bekomme.

Nun, wie wäre es, electron-global Upstream zu integrieren und es zum neuen Standard zu machen 😏