Electron: Erwartete App-Bundle-Größe?

Das ist die erwartete Größe, es gibt keine Möglichkeit, sie kleiner zu machen.

Ist es wirklich so groß zu erwarten? Meine gebündelten Windows- und Linux-Builds sind viel kleiner, und wenn man in den Electron Framework-Ordner schaut, gibt es drei Kopien der Electon Framework-Datei, jeweils eine:

InhaltFrameworksElectron Framework.framework
InhaltFrameworksElectron Framework.frameworkVersionsA
InhaltFrameworksElectron Framework.frameworkVersionsCurrent

Sollen das symbolische Links sein?

Wie klein sind die Windows- und Linux-Builds?

Darüber wundere ich mich auch. Hier sind die Größen für meine Elektronen-App:

osx - 117,3 MB
 linux32 - 60,3 MB
 linux64 - 55,2 MB
 ia32 gewinnen - 47,8 mb
 x64 gewinnen - 66,2 MB

Vielen Dank!

Ist geplant, die Größe des Frameworks in zukünftigen Versionen zu reduzieren? Dies macht es schwer, Electron für kleine Apps zu rechtfertigen (wo die Größe der App selbst von der Größe von Electron in den Schatten gestellt würde).

Ich kann bestätigen, dass meine Elektron-App-Bundles ungefähr die gleiche Größe wie @davefedele haben.

Sie können Ihre App zippen und wenn Sie electron-packager , können Sie einige Knotenmodule ignorieren, die Sie nicht benötigen, wenn die App ausgeführt wird. Dadurch wird sie etwas kleiner. Zum Beispiel habe ich eine 37 MB gezippte Electron-App (Beachten Sie, dass die Windows-Version viel größer ist, da sie eine Kopie von Git enthält).

Aber Electron wird immer einen großen Teil von Chrome enthalten, also kann nur so viel getan werden. Das Elektron selbst ist im Moment ~33 MB groß.

OS X komprimiert hat eine ähnliche Größe wie andere Plattformen, was wahrscheinlich bedeutet, dass die App, die Sie zum Messen von Größen verwenden, möglicherweise Symlinks falsch interpretiert.

In meinem Fall verwende ich eine Electron-Boilerplate , die nicht electron-packager und mein Electron-App-Ordner wird mit einem Python-Skript gezippt und über aws s3 verteilt. Mein erster Gedanke war jedoch, dass die Symlinks beim Komprimieren nicht berücksichtigt wurden (anstatt die Dateigröße falsch zu interpretieren).

Ich muss mir das mal ansehen, gibt es irgendwo eine Liste der vorhandenen Symlinks? Ich habe nur sehr begrenzten Zugriff auf einen Mac-Computer (ich verwende einen CI-Server, um meine App für jede Plattform zu packen).

paul<strong i="5">@psamathe</strong>:/Applications/Slack.app% find . -type l
./Contents/Frameworks/Electron Framework.framework/Electron Framework
./Contents/Frameworks/Electron Framework.framework/Libraries
./Contents/Frameworks/Electron Framework.framework/Resources
./Contents/Frameworks/Electron Framework.framework/Versions/Current
./Contents/Frameworks/Mantle.framework/Headers
./Contents/Frameworks/Mantle.framework/Mantle
./Contents/Frameworks/Mantle.framework/Modules
./Contents/Frameworks/Mantle.framework/Resources
./Contents/Frameworks/Mantle.framework/Versions/Current
./Contents/Frameworks/ReactiveCocoa.framework/Headers
./Contents/Frameworks/ReactiveCocoa.framework/Modules
./Contents/Frameworks/ReactiveCocoa.framework/ReactiveCocoa
./Contents/Frameworks/ReactiveCocoa.framework/Resources
./Contents/Frameworks/ReactiveCocoa.framework/Versions/Current
./Contents/Frameworks/Squirrel.framework/Headers
./Contents/Frameworks/Squirrel.framework/Modules
./Contents/Frameworks/Squirrel.framework/Resources
./Contents/Frameworks/Squirrel.framework/Squirrel
./Contents/Frameworks/Squirrel.framework/Versions/Current

Ich konnte dies gestern endlich überprüfen, und tatsächlich wurde mein Problem dadurch verursacht, dass Symlinks nicht erhalten wurden. Meine Anwendungsgröße ist also drastisch von ~110 MB auf ~45 MB geschrumpft.

@carlosperate Können Sie beschreiben, wie Sie Ihre Symlinks

Nun, es ist wichtig zu betonen, dass ich nicht electron-packager . Ich hatte ein Python-"Build-Skript" (das gleiche Skript läuft in Windows, Linux und OS x), das andere Dinge unabhängig von meiner Elektron-App erstellt. Wenn es dann auf einem Mac läuft, würde es alles in die allgemeinen OS X App-Bundle-Verzeichnisse kopieren und schließlich alles in eine einzige Datei zippen.

In meinem speziellen Fall gab es also zwei Probleme mit meinem Skript, ich habe die Elektronendateien kopiert, ohne Symlinks zu respektieren (sehr einfach zu beheben), und dann respektiert das zipfile Modul in Python auch die Symlinks nicht, was war nicht so einfach wie ich erwartet hatte. Wenn Sie nach Lösungen für das Problem googeln, finden Sie einige Artikel mit seltsamen Implementierungen, die eher der Magie als einer echten Erklärung ähneln zip CLI-Befehl mit den erforderlichen Flags zum Respektieren von Symlinks.

FWIW, wenn Sie eine ZIP-Datei unter Linux für die Verteilung an OS X erstellen, müssen Sie den Parameter -y , um Symlinks korrekt zu behandeln:

$ zip -r -y app.zip app

Was hat #SLACK bewirkt? Warum ist ihre App so klein?
Die Zip-Archivdatei ist 24,6 MB groß.

Die Windows- und Linux-Versionen sind mehr oder weniger das, was ich erwarten würde, ich frage mich, wie sie ihre OSX-Version so klein bekommen haben.

Zuletzt habe ich überprüft, dass Slack MacGap für die Mac-Seite verwendet

http://electron.atom.io/#built -on-electron Slack ist dort in der Liste.

Ja, die Windows- und Linux-Apps von Slack basieren auf Electron, aber die Mac-App verwendet MacGap.

@joshaber ich glaube du hast

Weißt du, ob Electron einen Plan zur Reduzierung der endgültigen Bundle-Größe hat? Das wäre unglaublich.

Weißt du, ob Electron einen Plan zur Reduzierung der endgültigen Bundle-Größe hat? Das wäre unglaublich.

Es gibt nur so viel, was Sie aus Chromium, Node.js, V8 usw. herausnehmen können und immer noch ein funktionierendes Produkt haben. Da leider alles gepatcht ist, um zu funktionieren, ist es nicht so einfach, eigenständige Versionen von jedem zu verwenden, um die Größe zu reduzieren. Ich bin sicher, das Electron-Team hätte gerne eine kleinere Größe. Aber man kann es einfach nicht planen und umsetzen. Es ist einfach zu ätzend für das Gesamtprojekt, zu denken, dass Sie selbst 10-20 MB Code und Ressourcen entfernen und erwarten können, dass alles stabil läuft.

So wahr @baconface ... Eine Sache hat mir hier jedoch geholfen: Ich habe Module wie Electron-Prebuilt, Electron-Builder und Electron-Packager und alle ihre Abhängigkeiten in den "App"-Ordner gelegt. Sie von package.json der App abzuschneiden und erneut zu erstellen, hat mir viel Größe gespart. Ich habe die two-package.json-Struktur von Electron-Builder verwendet.

@leonelcbraz Fühlen Sie sich frei, Ideen von meinem Ignore-Regex für electron-packager auszuleihen oder zu erhalten. Ich erstelle ausführbare Dateien im bin-Verzeichnis, habe ein src-Verzeichnis für nicht minimierte Quelldateien, verwende Grunt zum Erstellen und habe andere Dinge drin, die ich nicht brauchte. Wenn ich an einem Projekt arbeite, muss ich den Knotenkontext nicht verwenden, ich setze einfach nodeIntegration auf false und ignoriere das gesamte Verzeichnis node_modules. Dies hat meine Verteilungsgröße drastisch reduziert.

(^(/bin|/src)$|[Gg]runt(.*)|node_modules/grunt-(.*)|node_modules/electron-(.*))

Außerdem ist es nicht erforderlich, die two-package.json-Struktur zu verwenden. NPM unterstützt Entwicklerabhängigkeiten. Sie können eine über npm install <package name> --save-dev installieren. Sie werden dann feststellen, dass Sie in Ihrer package.json dependencies und devDependencies wobei Ihre Abhängigkeiten sauber getrennt sind. Wenn Sie die Regex ignorieren für electron-packager ändern, wie ich es oben getan habe, können Sie sie vollständig von Ihrer App isolieren und dennoch in einer normalen node.js-Umgebung arbeiten.

Edit: Es ist noch einfacher!

Das klingt nett. Ich danke Ihnen für das Teilen :)

Slack hat jetzt eine Electron-Beta des Mac-Clients. Die alte Mac-Binärdatei (mit MacGap) war 36 MB auf der Festplatte. Die neue Mac-Binärdatei (mit Electron) ist 175 MB groß. 124 MB davon ist das Electron Framework.

@NelsonMinar Das ist Leute . Sie müssen etwas mit der App-Größe tun.

Einverstanden.

Die Verwendung von @baconface ignore Regex hat sehr geholfen, die App-Größe zu reduzieren. Ich habe auch mehr der vorhandenen node_modules manuell ignoriert und meine App konnte ohne gut laufen, was mich auf etwa 50 MB Gesamtgröße der Mac-App und etwa 60 MB für Windows brachte.

@pierreraii Froh, dass es geholfen hat. Ein wichtiger Hinweis ist, dass NPM3 die Funktionsweise des Verzeichnisses node_module ändert . Infolgedessen funktioniert dieser Trick möglicherweise nicht nach Ihren Erwartungen. Sie können NPM jedoch mit npm i npm<strong i="7">@2</strong> -g auf Version 2 herabstufen.

In Zukunft wird unsere Lösung für unser Projekt bei der Arbeit NPM3 verwenden, aber alles, was wir nicht wollen, als Dev-Abhängigkeit bereitstellen. Wir installieren unsere Electron-Build-Tools global im Gegensatz zur Projektebene. Dann installieren Sie nur die benötigten Module mit npm install --only=production . Dies ist jedoch nicht ideal für Open-Source-Projekte, aber es funktioniert für unser Büro. Es ist bedauerlich, dass wir so ein seltsames Setup wie dieses haben müssen, aber es ist zweifelhaft, dass NPM jemals mit Electron im Hinterkopf entwickelt werden wird, da es nur ein Ausrutscher im NPM-Ökosystem ist.

Ja, Web-Entwickler zu sagen, dass sie sich oben mit Elektron befassen sollen, stellt sich als fast unmöglich heraus. Ich denke nur an eine Umgebung, die beides sein kann ... derzeit basiere ich meine Elektronen-Apps auf vorinstallierten Servern, da sie dies vor und für alle anderen können und idealerweise die gleichen Abhängigkeiten teilen. Wenn asar ein echter Benutzer fs sein könnte, dann würde ich Größen- und Kopierprobleme als gelöst betrachten, insbesondere bei nativen Erweiterungen

@baconface Sie müssen sich darüber keine Sorgen machen. Installiere einfach deine Abhängigkeiten wie gewohnt (prod deps in dependencies und dev deps in devDependencies ) und kopiere dann während der Paketierungsphase ( electron-packager erledigt das für dich) einfach deinen App-Ordner in ein temporäres Verzeichnis und führen Sie es aus.

npm prune --production

Dadurch werden alle Dev-Abhängigkeiten unabhängig von Ihrer NPM-Version zerstört, was zu der minimal möglichen Größe führt.

Sie können weitere 40-80% mehr gelöscht bekommen als nur mit --production

Sie können weitere 40-80% mehr gelöscht bekommen als nur mit --production

Wenn dies der Fall ist, sind Ihre Abhängigkeiten falsch konfiguriert, wenn Sie ein Modul löschen müssen und prune --production es nicht löscht, bedeutet dies, dass es als Produktionsabhängigkeit erkannt wurde. Wenn Sie es nach devDependencies wird es gelöscht.

oh sorry, vergessen zu sagen: wenn man eine Dateimaske baut, die readme, licence, ... löscht und node-gyp allein 100 mal mehr produziert

@xblox Ich kann mir nur vorstellen, dass diese Readmes / Lizenzen wie ein paar Kilobytes sind. Ein cooler neuer Trick besteht darin, yarn clean auszuführen, die diese Dinge automatisch für Sie löscht .

@MarshallOfSound Sie wären überrascht, insbesondere wenn Sie native Module verwenden. Es liegt viel Müll herum. Der yarn clean Ansatz könnte gut sein

@MarshallOfSound macht Ihre eigene Dateimaske , die jeden Cent wert ist, es ist immer überraschend, was in einigen Paketen enthalten ist. Und es sind durchaus mehr als nur ein paar Kilobyte, aber ich werde das Garn sauber überprüfen. danke für den hinweis.

@MarshallOfSound , @paulcbetts : nach dem Spielen mit yarn clean : es bereinigt nur etwa 70% von dem, was mit der erwähnten Dateimaske möglich ist

Wenn wir nur eine Hello-World-Anwendung ohne Abhängigkeiten von Knotenmodulen schreiben wollen, warum verzerrt dann der Packager immer noch alles? Die hochmoderne Lösung besteht darin, yarn clean , nicht wahr?

Meine node_modules sind 40 MB und Electron ist 140 MB

Mit dem Electron-Builder und diesem Datei-Glob gewinne ich ungefähr 80% auf meiner Desktop-App

files:[
"**/*",
                "!**/.*",
                '!buildResources{,/**/*}',
                '!**/node_modules/**/{CONTRIBUTORS,License,CNAME,AUTHOR,TODO,CONTRIBUTING,COPYING,INSTALL,NEWS,PORTING,Makefile,license,LICENCE,LICENSE,htdocs,CHANGELOG,ChangeLog,changelog,README,Readme,readme,test,sample,example,demo,composer.json,tsconfig.json,jsdoc.json,tslint.json,typings.json,gulpfile,bower.json,package-lock,Gruntfile,CMakeLists,karma.conf,yarn.lock}*',
                "!**/node_modules/**/{man,benchmark,node_modules,spec,cmake,browser,vagrant,doxy*,bin,obj,obj.target,example,examples,test,tests,doc,docs,msvc,Xcode,CVS,RCS,SCCS}{,/**/*}",
                "!**/node_modules/**/*.{conf,png,pc,coffee,txt,spec.js,ts,js.flow,html,def,jst,xml,ico,in,ac,sln,dsp,dsw,cmd,vcproj,vcxproj,vcxproj.filters,pdb,exp,obj,lib,map,md,sh,gypi,gyp,h,cpp,yml,log,tlog,Makefile,mk,c,cc,rc,xcodeproj,xcconfig,d.ts,yaml,hpp}",
                "!**/node_modules/**!(dom-to-image).min.js",
                "!**/node_modules/!(serialport|xpc-connection|unix-dgram|mraa)/build{,/**/*}", //prevent duplicate .node
                "!**/node_modules/**/node-v*-x64{,/**/*}", //prevent duplicate .node
                "!**/node_modules/contextify{,/**/*}",
                "!**/node_modules/jsdom{,/**/*}",
                "!**/node_modules/babe-runtime{,/**/*}",
                "!**/node_modules/bluebird/js/browser{,/**/*}",
                "!**/node_modules/xterm/dist{,/**/*}",
                "!**/node_modules/source-map/dist{,/**/*}",
                "!**/node_modules/lodash/fp{,/**/*}",
                "!**/node_modules/moment/src{,/**/*}",
                "!**/node_modules/moment/min{,/**/*}",
                // "!**/node_modules/moment/locale/!(fr.js|en.js|ja.js)",
                "!**/node_modules/async/!(dist|package.json)",
                "!**/node_modules/async/internal{,/**/*}",
                "!**/node_modules/ajv/dist{,/**/*}",
                "!**/node_modules/ajv/scripts{,/**/*}",
                "!**/node_modules/asn1/tst{,/**/*}",
                "!**/node_modules/axios/lib{,/**/*}",
                "!**/node_modules/axios/!(index.js|package.json)",
                "!**/node_modules/axios/dist/axios.min.js",
                "!**/node_modules/bluebird/js/browser{,/**/*}",
                "!**/node_modules/dom-to-image/src{,/**/*}",
                "!**/node_modules/xterm/src{,/**/*}",
                "!**/node_modules/qs/dist{,/**/*}",
                "!**/node_moduleslog4js/logs{,/**/*}",
                "!**/node_modulesi18next/!(index.js|package.json|dist)",
                "!**/node_modulesi18next/dist/!(commonjs)",
                "!**/node_modules/viewport-dimensions/dist{,/**/*}",
                "!**/node_modules/validator/!(lib|index.js|package.json|validator.js)",
                "!**/node_modules/moment-timezone/builds{,/**/*}",
                "!**/node_modules/moment-timezone/data/meta{,/**/*}",
                "!**/node_modules/moment-timezone/data/unpacked{,/**/*}",
                "!**/node_modules/node-pre-gyp/!(lib|package.json)",
                "!**/node_modules/node-pre-gyp/lib/!(util|pre-binding.js|node-pre-gyp.js)",
                "!**/node_modules/node-pre-gyp/lib/util/!(versioning.js|abi_crosswalk.json)",
                "!**/node_modules/ssh2/util{,/**/*}",
                "!**/node_modules/source-map-support/browser-source-map-support.js",
                "!**/node_modules/usb/!(package.json|src)",
                "!**/node_modules/opencv/!(package.json|lib)",
                "!**/node_modules/json-schema/!(package.json|lib)",
                "!**/node_modules/hawk/dist/{,/**/*}",
                "!**/node_modules/hawk/lib/browser.js",
]

Die Sache ist, dass es wirklich von den verwendeten Modulen abhängt, was die Wartung erschwert!

@farfromrefug Seien Sie beim Versand Ihrer App vorsichtig, wenn Sie Open-Source-Bibliotheken verwenden. Es besteht die Möglichkeit, dass die von Ihnen verwendeten Bibliotheken die Lizenzdatei mit allen Anwendungen benötigen und Sie alle blind entfernen.

@OmgImAlexis Eigentlich hast du Recht, ich sollte

Nur ein Kopf hoch. electron-packager ist intelligent genug, um Abhängigkeiten zu löschen, die in einem devDependencies . Also habe ich die meisten meiner Pakete dorthin verschoben und die Skripts, die ich verwende, in einer einzigen JS-Datei mit Grunt gebündelt. Jetzt sieht meine Regex für Ignorieren etwa so aus: "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|build.js)" . Gibt mir die gleichen Ergebnisse, ist aber viel einfacher und ich muss meiner Regex keine Abhängigkeitspfade manuell hinzufügen. Funktioniert sogar mit der Art und Weise, wie Yarn Abhängigkeiten speichert.

Ich hatte das Beispielprojekt vor kurzem zu Lernzwecken von https://github.com/electron/simple-samples.git geklont
Elektronenpaket C:userlearningnodeclonedAppsimple-samplesactivity-monitor cpu --platform=win32 --arch=x64 --ignore="node_modules"

Ich habe mich gefragt, ob die Bundle-Größe für eine einfache App 132 MB beträgt.
Gibt es eine Möglichkeit die Bündelgröße zu reduzieren?

Ich hätte vorgeschlagen, UPX auf Ihrer ausführbaren Datei zu verwenden, die plattformübergreifend ist, viele Architekturen unterstützt und kinderleicht zu bedienen ist, aber leider scheint Electrons Team es vorzuziehen, sich nicht zu beugen.
(Bereits früher angefordert: https://github.com/electron/electron/issues/5506)

Ansonsten hat mein Test gut funktioniert, indem ich NW.js mit UPX komprimiert
Wenn es also auf die Größe ankommt, könnten Sie sich vielleicht stattdessen auf die Entwicklung mit diesem konzentrieren?

Ich konnte meine komprimierte OSX-Distributionsgröße auf 52 MB erhöhen, indem ich electron und so ziemlich jedes andere Nicht-Laufzeit-Paket in devDependencies in package.json und so ziemlich jedes andere Nicht-Laufzeit-Paket unter rm -rf node_modules und dann npm install --production .

Beim Packen der App beschwerte sich electron-packager über eine fehlende electron Abhängigkeit in den node_modules des Projekts. Sie können dies umgehen, indem Sie electron-packager das folgende Flag bereitstellen:

--electron-version=1.7.11

Ersetzen Sie 1.7.11 durch Ihre gewünschte electron-packager Version.

@eladnava Vielen Dank für die Bereitstellung von Informationen. Ich werde die von Ihnen angegebenen Schritte überprüfen. Wenn ich die Anwendung in dmg umwandle, beträgt ihre Größe 53 MB.

Ich kenne/habe nicht alle vorherigen Nachrichten gelesen, also bitte sagen Sie mir, ob es schon gesagt wurde.

Ist es möglich, das Electron-Framework selbst zu trennen und nur die Apps auszuliefern?

Soweit ich weiß, ist die Lieferung von Electron-Apps in der fw enthalten. Es hört sich so an, als würde eine Java-App mit darin enthaltener JRE ausgeliefert.

Ist es möglich, ein Electron-Framework auf dem Betriebssystem zu installieren, damit alle Apps, die diese Version verwenden können, verwendet werden?

@eladnava Sie wissen, dass Ihre App nicht läuft, wenn Electron nicht auf dem Zielcomputer installiert ist?

@fab1an : Ich denke, dass @yasinaydin das versteht. Er möchte eine gemeinsame Electron-Runtime, die Benutzer für alle ihre Electron-nutzenden Anwendungen installieren können. Dies wird bereits in Elektron/Elektron #673 diskutiert, derzeit ohne Auflösung.

@js-choi @fab1an Ich bin mir nicht ganz sicher, wie es funktioniert, aber ich habe das Gefühl, dass Electron in electron-packager vorgebündelt ist , innerhalb des Electron Framework.framework , das in der verpackten App enthalten ist.

Daher gibt es keinen Grund, electron in den node_modules Ihrer App zu bündeln. Außerdem muss das Paket npm electron nicht auf dem Zielcomputer installiert werden, damit mein Ansatz funktioniert.

electricno konnte mit ihrer Technologie eine 115 MB große Electron-App auf nur 167 kB machen. Ich denke, diese Technologie muss in Electron integriert werden, eine 100 MB Hello World App ist einfach keine normale Größe um "Hello World" anzuzeigen :+1:

@spaceywolfi Da Electrino nicht wirklich die Chrome / V8-Engine zum Rendern Ihrer App

Sie können versuchen, den von mir erwähnten Trick zu verwenden, um die Basis-Binärgröße auf ~ 50 MB zu reduzieren.

@eladnava danke für die Erklärung!

@eladnava

Ich bin mir nicht ganz sicher, wie es funktioniert, aber ich habe das Gefühl, dass Electron im Electron-Packager im Electron Framework.framework vorgebündelt ist, das in der verpackten App enthalten ist.

Daher gibt es keinen Grund, Elektron auch innerhalb der node_modules Ihrer App zu bündeln. Herangehensweise an die Arbeit.

Ich habe electron und electron-packager in meinem devDependencies . Auf diese Weise kann ich electron ./dist/js/main.js einem Skript in meinem package.json zuweisen. Wenn Sie beispielsweise npm run launch ausführen, wird schnell eine entpackte Instanz meiner Electron-App gestartet, die zum Testen bereit ist. Zusätzlich verwendet electron-packager die für electron Version, sodass Ihre Paketversion mit Ihrer Testversion von Electron identisch ist. Es sollte auch electron und electron-packager automatisch aus der Ausgabe entfernen.

@baconbrad

Danke für deinen Tipp. Ich habe electron und electron-packager global installiert, um zu verhindern, dass sie in den node_modules Ordner der endgültigen Binärdatei gepackt werden. Ich habe festgestellt, dass electron-packager diese Abhängigkeiten nicht automatisch aus der endgültigen Binärdatei entfernt, was für mich zu einer Binärgröße von ~100 MB führte. Nach der globalen Installation dieser beiden Pakete sank die Binärgröße auf ~50 MB.

@eladnava Dies geschah wahrscheinlich, weil Sie sie als Abhängigkeit und nicht als npm install packagename --save-dev wird es im richtigen Bereich Ihres package.json . Es wird in Ihrem node_modules Ordner angezeigt, wird jedoch nach dem Verpacken entfernt.

@baconbrad

Dies ist durchaus möglich. Aber ich denke, dass, da neuere Versionen von npm alle Abhängigkeiten Ihrer Abhängigkeiten im Stammprojektordner node_modules/ npm installieren, diese möglicherweise von electron-packager in die endgültige Binärdatei gebündelt wurden .

Wissen Sie, ob electron-packager schlau genug ist, um diese devDependencies '-Abhängigkeiten auszulassen?

@eladnava

Wissen Sie, ob Elektron-Packager intelligent genug ist, um die Abhängigkeiten dieser devDependencies auszulassen?

Kann bestätigen, dass devDependencies Abhängigkeiten ausgelassen werden. Auch wenn Sie die neueste Version von NPM oder Yarn verwenden.

Außerdem sollten Sie ein Build-System wie Gulp oder Grunt verwenden, um Frontend-Abhängigkeiten zu bündeln und diese ebenfalls in devDependencies aufzulisten. Dies liegt daran, dass sie möglicherweise mit zusätzlichen Quelldateien oder ihren devDependencies . Das einzige Mal, dass ich etwas in meinem dependencies ist, weil ich es unbedingt versenden muss. Ihre Skripte möchten weiterhin im Knotenkontext ausgeführt werden, daher müssen Sie window.module = module; module = undefined; aufrufen, bevor Sie Ihre gebündelten Skripts im Browserkontext laden. Ich stelle dann sicher, dass mein Paketierer dies in der Ignorieroption "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)" . Durch das Ausführen all dieser Schritte wird im Grunde genommen ein übermäßiges Bulking von Abhängigkeiten oder das versehentliche Einschließen von Quelldateien oder Build-Ordnern vermieden.

@baconbrad

Prost für die Tipps Kumpel!

Hallo Leute,

Um die App-Größe für alle drastisch zu reduzieren, Bandbreite für alle zu sparen, den Build-Prozess für alle einfacher zu machen usw. muss die Optimierung/Denkweise anders gemacht werden, als nur einige node_modules zu ignorieren.

Wie wäre es mit der gleichen Idee, die Java und Java-Apps seit Jahrzehnten erfolgreich verwenden: eine Abhängigkeit von einer "JRE" (die in unserem Fall ein "ERE" wäre).

Auf diese Weise würde das ERE global auf dem Computer für die erste App installiert, die es benötigt (der Prozess der Anforderung des ERE könnte vom App-Installer für jede Plattform automatisiert werden), und dann würde jede neue App nur dieses vorhandene ERE verwenden .

Das ERE würde eine Auto-Update-Funktion und Abwärtskompatibilität (kein BCB!) benötigen, damit dies funktioniert, aber ich bin mir ziemlich sicher, dass dies trivial ist.

Dann würde jede Electron-App dann nur ein paar MB wiegen. Sparen Sie den Benutzern Zeit. Sparen Sie Entwicklern Zeit und Bandbreite und bauen Sie Komplexität auf.

Wurde es schon einmal vorgeschlagen? Wenn ja, wie wäre es dann? Ich denke, das ist der einzige und beste Weg.

@RenaudParis Ich habe es schon einmal vorgeschlagen und vielleicht noch ein paar mehr, aber ich habe bisher keine ernsthaften Werke gehört.

@yasinaydin Das habe ich mir schon gedacht, darüber müssen die Leute schon einmal nachgedacht haben.

Nun, irgendwelche Inputs vom Entwicklerteam? @zcbenz Das würde so viele Leute glücklich machen und Electron zukunftssicher machen (denn seien wir

Ist die JRE hier nicht ein großartiges Beispiel?

@RenaudParis und @yasinaydin , es gibt so viele Gründe, warum es nie zu einer globalen Installation von Elektron kommen wird.

Erstens werden von allen Produktions-Elektronen-Apps in der Wildnis vielleicht mehr als 20 verschiedene Versionen von Elektron verwendet. Für welche Version würden Sie sich weltweit entscheiden? Es ist so fragmentiert, weil Electron einen schnellen Release-Zyklus hat und Entwickler Zugriff auf die neuesten Chrome-Funktionen wünschen.

Unsere Apps werden nur mit einer einzigen Version von Electron getestet und warum sollten wir im Hinblick auf einen 40-MB-Download das Risiko und die Supportkosten eingehen, sie auf einer anderen zufälligen ungetesteten Version laufen zu lassen?

den Build-Prozess für alle einfacher machen

Viele Elektron-Apps verwenden native Module, die in den meisten Fällen gegen die spezifische Version des verwendeten Elektrons erstellt werden müssen. Wie würden Sie dieses Problem lösen?

Fühlen Sie sich frei, eine globale Version von Elektron zu erstellen, die Entwickler verwenden können, aber ich denke, Sie werden feststellen, dass kaum jemand sie aus den oben genannten Gründen verwenden würde!

@timfisch
there are so many reasons having a global install of electron will never happen.
Das klingt nach einem davon: https://www.pcworld.com/article/155984/worst_tech_predictions.html

Da Node/v8- oder Elektron-Binärdateien nicht so groß sind, kann ein globales ERE bei Bedarf fehlende Komponenten zur einmaligen Verwendung herunterladen. Für diese globalen EREs kann auch eine gewisse Bundle-Logik implementiert werden, wie Node.js 9.x anstelle von separaten Node.js 9.0, 9.1 usw..

Ich weiß nicht, aber ich glaube nicht, dass dies die Einstellung ist, Dinge zu tun ... "Oh, das geht nicht. Oh, es ist unmöglich. Macht keinen Sinn." Stattdessen sollte es lauten: "Wie können wir dieses x erreichen/umgehen?"

@timfish das sind traurige Neuigkeiten ... Ich persönlich interessiere mich nicht viel für eine 40-MB-Datei, aber 120 MB (wie ich gehört habe) sind jedoch ein bisschen zu viel für eine Hallo-Welt.

Erstens werden von allen Produktions-Elektronen-Apps in der Wildnis vielleicht mehr als 20 verschiedene Versionen von Elektron verwendet. Für welche Version würden Sie sich weltweit entscheiden?

Wie gesagt, Abwärtskompatibilität wäre erforderlich.

Entwickler möchten Zugriff auf die neuesten Chrome-Funktionen

Daher progressive Verbesserung... Richtig? In jedem Fall ist auch eine schrittweise Erweiterung nicht zwingend erforderlich, wenn eine App eine bestimmte Version des ERE erfordern kann, was eine Aktualisierung des globalen ERE auslösen würde.

Wie würden Sie dieses Problem lösen?

Wenn einige Leute speziell kompilierte Module benötigen, steht es ihnen frei, ihre eigene benutzerdefinierte Version der Module einzubetten (die ohnehin nicht im ERE verfügbar wäre) und eine Mindestversion des ERE anzugeben. Wenn das ERE auf eine neuere Version aktualisiert wird, gibt es wohl zwei offensichtliche Lösungen: Entweder aktualisieren sie ihre Module (wie bei den Abhängigkeiten in Node heute) oder wir könnten auch mehrere globale Versionen von ERE zulassen (wie die JRE). Ich denke, das ist kein Thema.

Elektron hat einen schnellen Freisetzungszyklus

Das ist großartig, kein Zweifel hier. Aber vielleicht könnten die Leute mit einer monatlichen Veröffentlichung überleben, was die Anzahl der ERE-Versionen begrenzt.

Zögern Sie nicht, eine globale Version zu erstellen

Ja... Das werde ich nicht tun. Ich habe nicht die Fähigkeiten, aber ich würde es tun, wenn ich sie hätte.

Ich kann nur Vorschläge machen, die ich für relevant halte, und die Experten ihre Arbeit machen lassen: Entweder sie sagen mir, ich sei ein Idiot mit meinen Vorschlägen (was sehr wohl der Fall sein kann), oder sie meinen, es könnte etwas Schönes ergeben . Wie auch immer :)

Ich denke immer noch, ein globales ERE wäre die beste Lösung, auch wenn es bedeutet, mehrere EREs für die verschiedenen Bedürfnisse der verschiedenen Apps zu haben. Aber auch dies ist nur eine Idee, die ich beim Vergleich mit der JRE hatte.

@RenaudParis

Das sind traurige Neuigkeiten... Ich persönlich interessiere mich nicht viel für eine 40 MB Datei, aber 120 MB (wie ich gehört habe) sind jedoch ein bisschen zu viel für eine Hallo Welt.

120 MB sind unkomprimiert, wenn Sie es komprimieren, sind es etwa 40 MB. VSCode 64-Bit für die Windows-Installations-EXE ist beispielsweise etwa 42,8 MB groß.

Persönlich würde ich als Benutzer immer lieber eine eigenständige Anwendung haben, ohne die globale JRE (oder ERE) verwalten zu müssen, selbst wenn ich 200 MB statt 10 MB herunterladen muss.

Es ist nicht nur 120 MB, ich habe eine einfache Webanwendung erstellt, die ~ 1 MB auf dem Webserver war, aber ~ 300 MB als Electron-App unter OS X

Außerdem wird dies wichtiger, wenn viele Electron-Apps auf demselben Computer ausgeführt werden.
Dann wird es 10 mal, 20 mal größer.
Es gibt jetzt mehrere Standard-Apps auf einem Computer, die mit Electron erstellt wurden, wie Slack, VSCode usw. Und es gibt noch größere Projekte wie NodeOS.

Node.js hat >500k Module. Wenn Electron besser & schneller & beliebter & kleiner werden würde, gäbe es viel mehr Apps auf einem Desktop mit GBs unnötiger Electron-Dateien.

Electron ist einfach nicht das beste Framework.

Ich würde eher versuchen, nicht benötigte Teile des Chrome-Frameworks wie Flash usw.

@yasinaydin

1 MB auf Webserver, aber ~300 MB als Electron-App unter OS X

Sie müssen Ihre Anwendung vor der Verteilung bereinigen (Hinweis: Überprüfen Sie Ihre node_modules). Beispielsweise ist VSCode unter Windows nach der Installation 228 MB groß (die herunterladbare Installation ist nur 42,8 MB groß).

Die Installationsgröße ist jedoch nur ein Problem. Ein anderes Problem ist die Verwendung von RAM und die Startzeit. Nach meiner Erfahrung ist die Anwendungsgeschwindigkeit nach dem Start der Anwendung kein Problem.

Electron ist für kleine Anwendungen nicht gut geeignet, aber für große Anwendungen wie VSCode funktioniert es.

Anderes Problem ist, wie viel RAM-Anwendung verwendet und Startzeit

@mvladic meinst du nicht, dass genau das zwei weitere Probleme sind, die ein ERE beheben würde? Bereits geladen und zwischen Apps und allen geteilt.

Okay, vielleicht haben die Leute nicht 10 Electron-Apps gleichzeitig laufen ... Aber vielleicht werden sie es tun! Es ist wichtig, Abhängigkeiten so weit wie möglich zu faktorisieren.

Ich verstehe, dass Electron zuerst als POC gestartet wurde und dann sehr häufige Releases benötigte, um die Entwickler zufrieden zu stellen. Aber vielleicht müssen jetzt, da Electron ausgereifter ist, einige Maßnahmen ergriffen werden, um die bestmögliche {Ladezeit, RAM-Nutzung, Downloadgröße} zu gewährleisten.

Auch hier schlage ich nur eine (naive, vielleicht, ich weiß es nicht) Lösung für Probleme vor, über die Electron-Benutzer von Anfang an zu schimpfen scheinen. Aber was mich betrifft, stört mich der aktuelle Stand von Electron wirklich nicht für meine eigenen kleinen Bedürfnisse. Electron ist großartig, ich denke nur über Möglichkeiten nach, es noch besser zu machen.

Electron ist einfach nicht das beste Framework.

@fab1an , hängt davon ab, was die Leute brauchen. Für mich ist es perfekt für meine Bedürfnisse geeignet, da ich mir nicht sicher bin, ob PWAs ausgereift genug sind. Aber vielleicht wäre Qt für andere Leute besser geeignet, da hast du Recht.

Eine Laufzeit wurde bereits vorgeschlagen und diskutiert und ist immer noch eine offene Diskussion . Aber das ist eines der Dinge, die leichter gesagt als getan sind. Wie Sie sehen, ist es nicht jedem gelungen, auf die gleiche Seite zu kommen oder herauszufinden, wie man es richtig auf den Weg bringt, damit es in der Produktion zuverlässig funktioniert. Wenn Sie denken, dass Sie zu der Diskussion beitragen oder helfen können, sie in Gang zu bringen, denke ich, dass die zusätzliche Hilfe niemandem etwas ausmachen würde.

Viele Entwickler, darunter auch ich, sind ziemlich zufrieden damit, einen 40-Meg-Download herauszugeben und ihn mit kleineren Delta-Updates zu aktualisieren. Die Leute haben heute kein Problem damit, ein 40-Meg-Programm herunterzuladen. Und sogar kleine Programme da draußen, die eine Datei mit ein paar Megabyte sind, können 40 Megabyte herunterladen und installieren - 2 Gigs und niemand scheint ein Problem zu haben. damit. Selbst wenn eine Laufzeitoption verfügbar war, besteht die Möglichkeit, dass ein Benutzer sie nicht hat und trotzdem über 40 MB herunterladen muss, um Ihr Projekt auszuführen.

Wenn dieser Vorbehalt nicht Ihr Ding ist, suchen Sie bei Bedarf nach einer anderen Option. Ich meine das nicht direkt, manchmal muss man Technologien eliminieren, um das Ziel und die Bedingungen zu erreichen, die man erfüllen möchte. Aber das macht Electron nicht zu einer schlechten Technologie oder für viele andere unbrauchbar. Elektron soll nicht jede Lösung lösen. Und das wird es realistischerweise auch nie.

@baconbrad Wenn Ihr Kommentar auf mich abzielt, verstehe ich nicht warum, da ich mehrmals ausdrücklich gesagt habe, dass ich so wie es ist, ziemlich glücklich bin und dass Electron genau die Technologie war, die für meine (spezifischen) Bedürfnisse geeignet ist.

Ich sagte nur, dass ich überall viele Leute gesehen habe, die sich über die Paketgröße beschwerten, und ich bot nur eine (wieder naive) Lösung für dieses Problem an, die mir ideal erschien. Aber ich kann mich sehr wohl irren und auf jeden Fall wird es mich absolut nicht daran hindern, Electron für meine zukünftigen Bedürfnisse zu verwenden :)

Selbst wenn eine Laufzeitoption verfügbar war, besteht die Möglichkeit, dass ein Benutzer sie nicht hat und trotzdem über 40 MB herunterladen muss, um Ihr Projekt auszuführen.

Ja, aber ich kenne viele Leute, sogar hier im Zentrum von Paris, die nur eine 5-Mbit/s-Internetverbindung haben, und für diese Leute bedeutet das Einsparen von 40 MB (dh 320 MB) für jede App, jedes Mal ein paar Minuten zu sparen, wenn die App aktualisiert wird (nicht vergessen Sie, dass die 40 MB für jedes Update verwendet werden, nicht nur für die erste Installation), da ihre Internetverbindung nicht verwendet wird.

Dabei sind die RAM-Einsparungen, insbesondere bei Notebooks, noch nicht einmal berücksichtigt. Auch hier fühle ich mich persönlich nicht betroffen, da ich eine relativ gute Maschine mit 32 GB RAM habe, aber ich denke hier nicht an mich, sondern an die Leute, die sich beschweren und hoffen, eine Lösung für sie zu finden.

Zu guter Letzt haben Sie vielleicht eine gute Verbindung, und ich auch (eine blitzschnelle, wenn Sie bitte! :) ), und wir können beide 16 oder 32 oder 64 GB RAM haben, deshalb Es macht Ihnen nichts aus, die 40 MB für jedes Update herunterzuladen, aber was ist mit Ihren Benutzern (vorausgesetzt, Sie verteilen Ihre App an andere)?

Wie auch immer, ich werde mich nicht darum streiten, ich wollte nur helfen, und wie gesagt, ich bin ziemlich glücklich so wie es ist und ich habe viele Dinge zu erledigen.

Wenn einige Leute denken, dass ich ihnen helfen kann, eine Lösung zu finden, helfe ich gerne, aber ansonsten gehe ich wieder an die Arbeit :)

Danke schön,

Eine Sache, die ich beim Verschieben von mehr Abhängigkeiten in devDependencies gesehen habe, ist, dass es umso mehr Zeit benötigt, um sie zu erstellen.

````
✔ Hauptprozess aufbauen

• Gebäude-Renderer-Prozess
  ````

Es hat viel mehr Zeit damit verbracht, den Renderer-Prozess zu erstellen, und das animierte Symbol stoppte, als ob es abstürzte, aber es tat es nicht. Dann werden 203778 ms aus dem Renderer-Bericht angezeigt.

Verschieben von devDependencies zurück in Abhängigkeiten, die Build-Zeit ist wieder normal, aber die App ist groß.

Wenn während des Builds kein Fehler auftritt, bedeutet dies, dass alles in Ordnung ist, oder?

@karimhossenbux Das ist für mich normal. Es gibt eine Walk-Funktion in electron-packager , die alle Abhängigkeiten durchläuft, um zu bestimmen, ob sie vorhanden sein sollten oder nicht. Mit den neuen flachen Abhängigkeiten anstelle der verschachtelten wird es viel länger dauern, nicht benötigte Abhängigkeiten zu bestimmen. Soweit ich weiß, gibt es keine Möglichkeit, die zusätzliche Bauzeit zu umgehen.

@baconbrad Danke! Ich verwende electron-builder aber ich denke, es funktioniert genauso.

Gibt es einen Elektronenpaket-Builder, der nur Ihre Quelle enthält und andere herunterlädt (nur für das aktuelle Betriebssystem erforderlich, auf dem der Benutzer ausgeführt wird), wenn der Benutzer Ihre App zum ersten Mal ausführt?. Es würde die Verteilung erleichtern und sollte Ihre App-Größe erheblich reduzieren.

Electron, bitte geh nicht den "ERE"-Weg. Ja, ich weiß, dass Sie aufgebläht sind, aber ich liebe es, wie Leute meine Anwendung herunterladen können und sie läuft einfach großartig, ohne dass Sie mit der Installation von Deps, der Aktualisierung der Laufzeitumgebung oder irgendwelchem ​​Unsinn herumspielen müssen, von dem ich dachte, dass wir ihn um 2003 losgeworden sind .

Nun, das Herunterladen eines Bundles wäre immer noch eine Option. Nichts zu beanstanden
ungefähr hier :)

Le ven. 25. Mai 2018 bis 21:03, Luke Pighetti [email protected] a
schreiben:

Electron, bitte geh nicht den "ERE"-Weg. Ja, ich weiß, du bist aufgebläht,
aber ich liebe es, wie Leute meine Anwendung herunterladen können und sie läuft einfach großartig
ohne sich mit Deps installieren und Runtime rumschrauben zu müssen
Umwelt, oder irgendeinen von diesem Unsinn, von dem ich dachte, dass wir ihn ungefähr losgeworden sind
2003.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/electron/electron/issues/2003#issuecomment-392151709 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AApUIBjAeVZ7T4SKo8LyW6RT65XnpiKgks5t2FWfgaJpZM4FGGer
.

Ich warte nur darauf, dass Microsoft-Ingenieure Electron verbessern.
https://news.ycombinator.com/item?id=17229973

Ich warte nur darauf, dass Microsoft-Ingenieure Electron verbessern.
https://news.ycombinator.com/item?id=17229973

@zcmgyu Microsoft beschäftigt seit einigen Jahren Entwickler, die an Electron arbeiten, seit sie es für VS Code verwenden. Und sie sind einige der größten Beitragenden und haben es ziemlich verbessert.

Wenn Ihre Anwendung mehr als 100 MB umfasst,
es kann sein, dass Ihre exe einen guten Teil Ihres node_modules-Ordners enthält.
Beachten Sie, dass alles, was in package.json in Abhängigkeiten deklariert ist, wieder in die endgültige ausführbare Datei importiert wird.
(Sehr einfach zu überprüfen: Es reicht aus, die ausführbare Datei zu dekompilieren)
Denken Sie also daran, nur die wesentlichen Bibliotheken in Abhängigkeiten (Elektronen-Log, Elektron-Updater) zu definieren und alle anderen Bibliotheken in devDependencies hinzuzufügen.

Deine App wird dann "nur" 50MB...

Meine App ist klein – hier ist das Repo. Die neueste experimentelle Version wiegt etwa 700 MB
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

Darüber wundere ich mich auch. Hier sind die Größen für meine Elektronen-App:

  osx - 117.3 mb

linux32 - 60,3 MB
linux64 - 55,2 MB
ia32 gewinnen - 47,8 mb
x64 gewinnen - 66,2 MB
Vielen Dank!

Tolle! Könnten Sie uns sagen, wie Sie die Elektronen-App auf eine so kleine Größe reduzieren können?