Electron: 予想されるアプリバンドルサイズは？

これは予想されるサイズであり、小さくする方法はありません。

本当にそんなに大きいと予想されますか？ バンドルされているウィンドウとLinuxビルドははるかに小さく、Electron Frameworkフォルダーを調べると、ElectonFrameworkファイルのコピーが3つあります。それぞれに1つずつあります。

コンテンツFrameworksElectronFramework.framework
コンテンツFrameworksElectronFramework.frameworkVersionsA
コンテンツFrameworksElectronFramework.frameworkVersionsCurrent

これらはシンボリックリンクであると想定されていますか？

WindowsとLinuxのビルドはどれくらい小さいですか？

私もこれについて疑問に思っています。 これが私のエレクトロンアプリのサイズです：

osx-117.3 mb
 linux32-60.3 mb
 linux64-55.2 mb
 ia32に勝つ-47.8mb
 x64で勝つ-66.2mb

ありがとう！

将来のリリースでフレームワークのサイズを縮小しようとする計画はありますか？ これにより、小さなアプリにElectronを使用することを正当化することが難しくなります（アプリ自体のサイズがElectronのサイズよりも小さくなります）。

私のelectronアプリバンドルが@davefedeleとほぼ同じサイズであることを確認できます。

アプリを圧縮できます。 electron-packagerを使用している場合は、アプリの実行時に不要なノードモジュールを無視できます。これにより、アプリが少し小さくなります。 たとえば、37MBのzip形式の

ただし、Electronには常にChromeの大部分が含まれているため、実行できることは非常に限られています。 現在のElectron自体は約33MBです。

圧縮されたOSXは他のプラットフォームと同様のサイズです。これは、サイズの測定に使用しているアプリがシンボリックリンクを誤って解釈している可能性があることを意味しますか？

私の場合、 electron-packagerを使用しないelectron-boilerplateを使用しており、electron appフォルダーはpythonスクリプトで圧縮され、awss3を介して配布されます。 だから私の最初は、圧縮時にシンボリックリンクが尊重されなかったということでした（ファイルサイズが誤って解釈されるのではなく）。

私はそれを調べる必要があります、存在するシンボリックリンクのリストはどこかにありますか？ Macコンピューターへのアクセスが非常に制限されています（プラットフォームごとにアプリをパックするためにCIサーバーを使用しています）。

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

私はついに昨日これを調べることができました、そして確かに私の問題はシンボリックリンクが保存されていないことが原因でした。 そのため、私のアプリケーションサイズは約110Mbsから約45Mbsに大幅に縮小しました。

@carlosperateシンボリックリンクをどのように修正したか説明していただけますか？

さて、私はelectron-packagerを使用していないことを強調することが重要です。 私のelectronアプリとは独立した他のものをビルドするPython「ビルドスクリプト」（同じスクリプトがWindows、Linux、OS Xで実行されます）があり、Macで実行すると、すべてが一般的なOSXアプリバンドルディレクトリにコピーされます。最後に、すべてを1つのファイルに圧縮します。

したがって、私の特定のケースでは、スクリプトに2つの問題がありました。つまり、シンボリックリンクを尊重せずに電子ファイルをコピーしていました（修正が非常に簡単です）。その後、Pythonのzipfileモジュールもシンボリックリンクを尊重していませんでした。思ったほど簡単ではありませんでした。 問題の解決策をグーグルで検索すると、実際の説明よりも魔法に近い奇妙な実装の記事がいくつか見つかるので、しばらくしてそれを機能させようとして失敗した後、osxを実行するサブプロセスを実行することになりましたzipシンボリックリンクを尊重するために必要なフラグを指定したCLIコマンド。

FWIW、OS Xに配布するためにLinuxでzipを作成する場合、シンボリックリンクを正しく処理するには-yパラメーターを使用する必要があります。

$ zip -r -y app.zip app

#SLACKは何をしましたか？ なぜ彼らのアプリはとても小さいのですか？
zipアーカイブファイルは24.6MBです。

WindowsとLinuxのバージョンは多かれ少なかれ私が期待しているものですが、OSXのバージョンがどうしてこんなに小さいのだろうかと思います。

最後に、 SlackがMac側に

http://electron.atom.io/#built -on-electronSlackがリストにあります。

はい、SlackのWindowsおよびLinuxアプリはElectron上に構築されていますが、MacアプリはMacGapを使用しています。

@joshaberあなたは正しいと思います。 SlackMacアプリはわずか36MBです。

Electronが最終的なバンドルサイズを縮小する計画があるかどうか知っていますか？ それは信じられないでしょう。

Electronが最終的なバンドルサイズを縮小する計画があるかどうか知っていますか？ それは信じられないでしょう。

Chromium、Node.js、V8などから取り出しても、まだ機能している製品はたくさんあります。 残念ながら、すべてが機能するようにパッチが適用されているため、それぞれのスタンドアロンバージョンを使用してサイズを縮小するほど簡単ではありません。 Electronチームはもっと小さいサイズを望んでいると確信しています。 しかし、計画を立ててそれを実現することはできません。 プロジェクト全体では、10〜20メガバイトのコードとリソースを削除して、すべてが安定して実行されることを期待できると考えるのは非常に苛酷です。

本当の@baconface ...ここで私を助けてくれたのは1つです。私は、electron-prebuilt、electron-builder、electron-packagerなどのモジュールとそれらのすべての依存関係を「app」フォルダーに入れていました。 それらをアプリのpackage.jsonから切り離し、再度ビルドすることで、サイズを大幅に節約できました。 私はelectron-builderのtwo-package.json構造を使用しました。

@leonelcbraz electron-packager 、無視する正規表現からアイデアを借りたり、入手したりしてください。 私はbinディレクトリに実行可能ファイルを作成し、縮小されていないソースファイル用のsrcディレクトリを持ち、ビルドにGruntを使用し、そこに必要のない他のものを持っています。 プロジェクトで作業する場合、ノードコンテキストを使用する必要はありません。 nodeIntegrationをfalse 、node_modulesディレクトリ全体を無視します。 これにより、配布サイズが大幅に削減されました。

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

さらに、two-package.json構造を使用する必要はありません。 NPMは開発者の依存関係をサポートしています。 npm install <package name> --save-devからインストールできます。 次に、package.jsonに、依存関係が適切に分離されたdependenciesとdevDependenciesがあることに気付くでしょう。 上記のようにelectron-packagerの無視正規表現を変更すると、アプリから完全に分離できますが、通常のnode.js環境で機能します。

編集：これよりもさらに簡単です！

いいですね。 共有していただきありがとうございます ：）

Slackには、MacクライアントのElectronベータ版があります。 古いMacバイナリ（MacGapを使用）はディスク上で36MBでした。 新しいMacバイナリ（Electronを使用）は175MBです。 その124MBがElectronFrameworkです。

@NelsonMinarこれは

同意しました。

@baconface ignore regexを使用すると、アプリのサイズを減らすのに大いに役立ちました。また、そこにあるnode_modulesを手動で無視しました。アプリはなくても正常に実行でき、Macアプリの合計サイズは約50MB、Windowsの場合は約60MBになりました。

@pierreraiiお役に立ててうれしいです。 重要な注意点は、 NPM3がnode_moduleディレクトリの動作方法を変更することです。 結果として、このトリックはあなたの期待に合わないかもしれません。 ただし、 npm i npm<strong i="7">@2</strong> -gを使用してNPMをバージョン2にダウングレードできます。

将来、私たちのプロジェクトのソリューションはNPM3を使用しますが、不要なものはすべて開発者の依存関係として出荷されます。 プロジェクトレベルではなく、Electronビルドツールをグローバルにインストールします。 次に、 npm install --only=production必要なモジュールのみをインストールします。 ただし、これはオープンソースプロジェクトには理想的ではありませんが、私たちのオフィスでは機能します。 このような奇妙な設定が必要になるのは残念ですが、NPMエコシステムのほんの一瞬であるため、NPMがElectronを念頭に置いて設計されることは疑わしいです。

ええ、ウェブ開発者に一番上の電子を扱うように言うことはほとんど不可能であることがわかります。 両方の環境を考えているだけです...現在、私は電子アプリを事前にデプロイされたサーバーに基づいています。これは、他のすべてのサーバーの前と他のすべてのサーバーで、理想的には同じ依存関係を共有できるためです。 asarが実際のユーザーfsである可能性がある場合、特にネイティブ拡張機能を使用すると、サイズとコピーの問題が解決されたと見なされます。

@baconfaceそのことについて心配する必要はありません。 通常のように依存関係をインストールし（prod depsをdependencies 、dev depsをdevDependencies ）、パッケージ化フェーズ中に（ electron-packagerがこれを行います）、アプリフォルダーをコピーするだけです。一時ディレクトリに移動して実行します。

npm prune --production

これにより、NPMのバージョンに関係なく、すべての開発者の依存関係が破棄され、可能な限り最小のサイズになります。

--productionを使用した場合よりも、さらに40〜80％以上削除される可能性があります

--productionを使用した場合よりも、さらに40〜80％以上削除される可能性があります

その場合、依存関係が正しく構成されていませんprune --productionモジュールを削除する必要があり、 devDependencies移動すると、削除されます。

申し訳ありませんが、言うのを忘れました：readme、license、...を削除するファイルマスクを作成すると、node-gypだけで100倍以上生成されます

@xblox私はそれらのreadmes /ライセンスなどを想像することしかできません。数キロバイトのトップスのようなものです。クールな新しいトリックはyarn cleanを実行することです。これにより、これらのものが自動的に消去されます。

@MarshallOfSound特にネイティブモジュールを使用している場合は、驚くでしょう。 たくさんのゴミが散らばっています。 yarn cleanアプローチは良いものかもしれません

@MarshallOfSoundは、すべてのペニーに値する独自のファイルマスクを実行します。これは、一部のパッケージの内容が常に驚くべきことです。 そして、それはほんの数キロバイト以上ですが、私は糸をきれいにチェックします。 ポインタをありがとう。

@ MarshallOfSound 、 @ paulcbetts ： yarn clean遊んだ後：前述のファイルマスクで可能なことの約70％しかクリーンアップしません

ノードモジュールの依存関係なしでhelloworldアプリケーションを作成したいだけの場合、パッケージャーがまだすべてをワープするのはなぜですか？ 最先端の解決策はyarn cleanを使用することですよね？

私のnode_modulesは40MBで、electronは140MBです。

電子ビルダーとこのファイルグロブを使用すると、デスクトップアプリで約80％増加します

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

重要なのは、使用するモジュールに本当に依存しているため、保守が面倒なことです。

@farfromrefugは、オープンソースライブラリを使用している場合はアプリの出荷に注意してください。使用しているライブラリですべてのアプリケーションにライセンスファイルを同梱する必要があり、やみくもにすべてを削除している可能性があります。

@OmgImAlexis実際、あなたは正しいです。ライセンスファイルを保持する必要があります。 ありがとう！

ただ頭を上げてください。 electron-packagerは、 devDependenciesリストされている依存関係を削除するのに十分賢いです。 そこで、ほとんどのパッケージをそこに移動し、Gruntを使用して使用するスクリプトを単一のJSファイルにバンドルしました。 したがって、無視するための正規表現は、この"(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|build.js)"ます。 同じ結果が得られますが、はるかに簡単で、正規表現に依存関係パスを手動で追加する必要はありません。 Yarnが依存関係を保存する方法でも機能します。

最近、 https：//github.com/electron/simple-samples.gitから学習目的でサンプルプロジェクトのクローンを作成しました
electronic-packager C：userlearningnodeclonedAppsimple-samplesactivity-monitor cpu --platform = win32 --arch = x64 --ignore = "node_modules"

単純なアプリのバンドルサイズは132Mbだろうかと思いました。
バンドルサイズを減らす方法はありますか？

クロスプラットフォームで、多くのアーキテクチャをサポートし、非常に使いやすい実行可能ファイルでUPXを使用することをお勧めしますが、残念ながら、Electronのチームはこれに屈することを好まないようです。
（以前にリクエスト済み：https：//github.com/electron/electron/issues/5506）

それ以外の場合、最新バージョンでまだ機能するかどうかは試していませんが、UPX（最終サイズが約60％小さい）でNW.jsを圧縮することでテストはうまく機能しました...
それで、サイズが重要な場合は、代わりにこれを使用して開発することに集中できますか？

私は移動することにより、52メガバイトに私のzip形式のOSXの配布サイズを取得することができましたelectronにし、ほとんどすべての他の非ランタイムパッケージをdevDependenciesでpackage.json 、実行中のrm -rf node_modules 、次にnpm install --production 。

アプリをパッケージ化するとき、 electron-packagerは、プロジェクトのnode_modules electron依存関係がないことを訴えます。 electron-packager次のフラグを指定することで、これを回避できます。

--electron-version=1.7.11

1.7.11を希望のelectron-packagerバージョンに置き換えます。

@eladnava情報を提供していただきありがとうございます。 あなたから提供された手順を確認します。 アプリケーションをdmgに変換すると、そのサイズは53MBになります。

以前のメッセージを全部知らない/読んでいないので、すでに言われている場合は教えてください。

Electronフレームワーク自体を分離して、アプリを出荷することは可能ですか？

私が理解している限り、Electronアプリの出荷方法はfwです。 JREが含まれているJavaアプリを出荷しているようです。

ElectronフレームワークをOSにインストールして、そのバージョンを使用できるすべてのアプリが使用できるようにすることは可能ですか？

@eladnavaターゲットマシンに電子がインストールされていないと、アプリが実行されないことに気づいていますか？

@ fab1an ： @yasinaydinはそれを理解していると思います。 彼は、ユーザーがすべてのElectronを使用するアプリケーションにインストールできるElectron共通ランタイムを望んでいます。 これはすでにelectron / electronic＃673で議論されており、現在は解決されていません。

@ js-choi @ fab1anそれがどのように機能するかは完全にはElectron Framework.framework内のelectron-packagerに事前にバンドルされているように感じます。

したがって、アプリのnode_modules内にelectronもバンドルする理由はありません。 また、私のアプローチを機能させるために、npm electronパッケージをターゲットマシンにインストールする必要はありません。

エレクトリノは、自社の技術を使用して、115MBのElectronアプリをわずか167kBにすることができました。 このテクノロジーはelectronに統合する必要があると思います。100MBのHelloWorldアプリは、「HelloWorld」を表示するための通常のサイズではありません：+1：

@spaceywolfiElectrinoは実際にはアプリをレンダリングするためにChrome / V8エンジンを実行していませんが、OSXのネイティブWebブラウザーエンジン（WebKit）を使用しているため、特にElectrinoを使用する場合は、Electronアプリを使用してビルドすることはできません。 Electron APIは、そこでは利用できないためです。 少なくともまだです。

私が述べたトリックを使って、ベースのバイナリサイズを最大50MBまで下げることができます。

@eladnava説明ありがとうございます！

@eladnava

それがどのように機能するかは完全にはわかりませんが、Electronは、パッケージ化されたアプリに含まれているElectronFramework.framework内のelectron-packagerに事前にバンドルされているように感じます。

したがって、アプリのnode_modules内にも電子をバンドルする理由はありません。 仕事へのアプローチ。

私が持っているelectronとelectron-packager私の中にdevDependencies 。 このようにして、 package.jsonスクリプトにelectron ./dist/js/main.jsを割り当てることができます。 たとえば、 npm run launchを実行すると、パッケージ化されていない、すぐにテストできるElectronアプリのインスタンスがすぐに起動します。 さらに、 electron-packagerはelectronリストされているバージョンを使用するため、パッケージ化されたバージョンはElectronのテストバージョンと同じです。 また、出力からelectronとelectron-packagerも自動的に削除する必要があります。

@baconbrad

チップをありがとう。 最終的にelectronとelectron-packagerグローバルにインストールして、最終的なバイナリのnode_modulesフォルダーにパッケージ化されないようにしました。 electron-packagerは、これらの依存関係を最終的なバイナリから自動的に削除しなかったため、バイナリサイズは約100MBになりました。 これら2つのパッケージをグローバルにインストールした後、バイナリサイズは約50MBに減少しました。

@eladnavaこれは、npm install packagename --save-devを使用すると、 package.jsonの適切な領域に保存されます。 node_modulesフォルダに表示されますが、パッケージ化されると削除されます。

@baconbrad

これは確かに可能です。 しかし、新しいバージョンのnpmすべての依存関係の依存関係をルートプロジェクトのnode_modules/フォルダーにインストールするため、これらはelectron-packagerによって最終的なバイナリにバンドルされている可能性があります。 。

electron-packagerがそれらのdevDependencies '依存関係を省略するのに十分賢いかどうか知っていますか？

@eladnava

電子パッケージャーがそれらのdevDependenciesの依存関係を省略するのに十分賢いかどうか知っていますか？

devDependencies依存関係が省略されていることを確認できます。 最新バージョンのNPMまたはYarnを使用している場合でも。

また、GulpやGruntなどのビルドシステムを使用して、フロントエンドの依存関係をバンドルし、それらをdevDependenciesにもリストする必要があります。 これは、追加のソースファイルまたはdevDependenciesが付属している可能性があるためです。 dependencies何かがあるのは、絶対に発送する必要があるからです。 スクリプトは引き続きノードコンテキストで実行する必要があるため、バンドルされたスクリプトをブラウザコンテキストにロードする前に、 window.module = module; module = undefined;を呼び出す必要があります。 次に、パッケージャーの無視オプション"(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)"これがあることを確認します。 これらすべての手順を実行することで、基本的に、過度の依存関係のバルク化や、ソースファイルやビルドフォルダーを誤って含めることがなくなります。

@baconbrad

ヒントメイトに乾杯！

こんにちは、みんな、

すべての人のアプリサイズを大幅に削減し、すべての人の帯域幅を節約し、すべての人のビルドプロセスを容易にするなど、最適化/思考は、一部のnode_modulesを単に無視するのとは異なる方法で行う必要があります。

JavaおよびJavaアプリが何十年にもわたって正常に使用されてきたのと同じアイデアを使用してはどうでしょうか。「JRE」（この場合は「ERE」）に依存します。

そうすれば、EREは、それを必要とする最初のアプリのマシンにグローバルにインストールされ（EREを要求するプロセスは、各プラットフォームのアプリインストーラーによって自動化できます）、すべての新しいアプリは、この既存のこのEREのみを使用します。 。

EREが機能するには、自動更新機能と下位互換性（bcbなし！）が必要ですが、これは些細なことだと確信しています。

そうすると、すべてのElectronアプリの重みは数MBだけになります。 ユーザーの時間を節約します。 開発者の時間と帯域幅を節約し、複雑さを構築します。

以前に提案されたことがありますか？ もしそうなら、それではどうですか？ これが唯一の最善の方法だと思います。

@RenaudParis私は以前にそれを提案しましたが、おそらくそれ以上のことはありませんが、これまでのところ深刻な作品は聞いていません。

@yasinaydin私は同じくらい考えました、人々は以前にそれについて考えたに違いありません。

では、開発チームからの意見はありますか？ @zcbenzこれは非常に多くの人々を幸せにし、Electronの将来性を大きく

JREは、ここで従うべき優れた例ではありませんか？

@RenaudParisと@yasinaydin 、電子のグローバルインストールが決して起こらない理由はたくさんあります。

まず、世の中に出回っているすべてのプロダクションエレクトロンアプリの中で、おそらく20以上の異なるバージョンのエレクトロンが使用されています。 どのバージョンをグローバルに選択しますか？ 電子はリリースサイクルが速く、開発者は最新のChrome機能にアクセスしたいので、このように断片化されています。

私たちのアプリは単一バージョンのelectronでのみテストされており、40 MBのダウンロードのために、他のランダムなテストされていないバージョンでの実行を許可するリスクとサポートコストを実行するのはなぜですか？

誰にとってもビルドプロセスを簡単にします

多くの電子アプリはネイティブモジュールを使用しますが、ほとんどの場合、使用中の特定のバージョンの電子に対して構築する必要があります。 この問題をどのように解決しますか？

開発者が使用できる電子のグローバルバージョンを自由に作成してください。ただし、上記の理由から、ほとんど誰もがそれを使用しないことがわかると思います。

@timfish
there are so many reasons having a global install of electron will never happen.
それはこれらの1つのように聞こえます： //www.pcworld.com/article/155984/worst_tech_predictions.html

Node / v8または電子バイナリはそれほど大きくないため、グローバルEREは、必要に応じて、不足しているコンポーネントをダウンロードして1回使用できます。 また、個別のNode.js 9.0、9.1などの代わりにNode.js 9.xのように、これらのグローバルEREにいくつかのバンドルロジックを実装することもできます。

わかりませんが、それが何かをする態度だとは思いません...「ああ、それはできません。ああ、それは不可能です。意味がありません。」 代わりに、「このxをどのように達成/回避できますか？」

@timfishこれは悲しいニュースです...私は個人的に40MBのファイルについてはあまり気にしませんが、120MB（私が聞いたように）は、HelloWorldには少し多すぎます。

まず、世の中に出回っているすべてのプロダクションエレクトロンアプリの中で、おそらく20以上の異なるバージョンのエレクトロンが使用されています。 どのバージョンをグローバルに選択しますか？

私が言ったように、下位互換性が必要になります。

開発者は最新のChrome機能にアクセスしたい

したがって、プログレッシブエンハンスメント...そうですか？ いずれにせよ、アプリが特定のバージョンのEREを必要とし、グローバルEREの更新をトリガーする可能性がある場合は、プログレッシブエンハンスメントでさえ必須ではありません。

この問題をどのように解決しますか？

特別にコンパイルされたモジュールが必要な場合は、モジュールの独自のカスタムバージョンを自由に埋め込んで（いずれの場合もERE内では使用できません）、EREの最小バージョンを指定できます。 EREが新しいバージョンに更新された場合、2つの明らかな解決策があると思います。モジュールを更新する（今日のNodeの依存関係と同じ）か、EREの複数のグローバルバージョン（JREと同じ）を許可ます。 これは問題ではないと思います。

電子はリリースサイクルが速い

これは素晴らしいことです、間違いなくここにあります。 しかし、おそらく人々は毎月のリリースで生き残ることができるので、EREバージョンの量を制限します。

グローバルバージョンを自由に作成してください

ええ...そんなことはしません。 私にはスキルがありませんが、持っていればスキルはあります。

私は単に私が関連すると考える提案を提供し、専門家に彼らの仕事をさせることができます：彼らは私が私の提案でばかであると私に言うか（それは非常によくあるかもしれません）、または彼らはそれが何か良いものにつながるかもしれないと考えます。 なんでもいい ：）

さまざまなアプリのさまざまなニーズに対応する複数のEREを用意することを意味する場合でも、グローバルEREが最善のソリューションになると思います。 しかし、繰り返しになりますが、これは私がJREと比較して得たアイデアにすぎません。

@RenaudParis

これは悲しいニュースです...私は個人的に40MBのファイルについてはあまり気にしませんが、120MB（私が聞いたように）は、HelloWorldには少し多すぎます。

120MBは非圧縮ですが、圧縮すると約40MBになります。 たとえば、WindowsインストールEXEのVSCode64ビットは約42.8MBです。

個人的には、ユーザーとして、10MBではなく200MBをダウンロードする必要がある場合でも、グローバルJRE（またはERE）を管理する必要のない自己完結型のアプリケーションを常に使用したいと考えています。

120MBだけでなく、Webサーバーでは最大1MB、OSXではElectronアプリとして最大300MBの単純なWebアプリケーションを作成しました。

さらに、同じマシンで多数のElectronアプリが実行されている場合、これはより重要になります。
そうすると10倍、20倍大きくなります。
現在、Slack、VSCodeなどのElectronで構築されたコンピューターには複数の標準アプリがあります。また、NodeOSのようなさらに大きなプロジェクトもあります。

Node.jsには50万を超えるモジュールがあります。 Electronがより良く、より速く、より人気があり、より小さくなれば、デスクトップにはさらに多くのアプリがあり、GBの不要なElectronファイルがあります。

Electronは最高のフレームワークではありません。

FlashなどのChromeフレームワークの不要な部分を分割することを検討したいと思います。

@yasinaydin

Webサーバーでは1MB、OSXではElectronアプリとして最大300MB

配布する前にアプリケーションをクリーンアップする必要があります（ヒント：node_modulesを確認してください）。 たとえば、WindowsのVSCodeはインストール後228MBです（ダウンロード可能なインストールはわずか42.8MBです）。

ただし、インストールサイズは1つの問題にすぎません。他の問題は、RAMアプリケーションの使用量と起動時間です。 私の経験では、アプリケーションが起動されると、アプリケーションの速度は問題になりません。

Electronは小さなアプリケーションには適していませんが、VSCodeのような大きなアプリケーションには機能します。

その他の問題は、RAMアプリケーションが使用している量と起動時間です

@mvladic正確には、EREが修正するもう2つの問題だと思いませんか？ すでにロードされ、アプリ間で共有されています。

さて、多分人々は同時に10個のElectronアプリを実行していません...しかし多分彼らはそうするでしょう！ 依存関係を可能な限り因数分解することが重要です。

Electronは最初にPOCとしてリリースされ、その後、開発者を満足させるために非常に頻繁なリリースが必要だったことがわかりました。 しかし、Electronがより成熟した今、可能な限り最高の{ロード時間、RAM使用量、ダウンロードサイズ}を確保するためにいくつかの対策を講じる必要があります。

繰り返しになりますが、私は、Electronユーザーが最初から怒鳴っているように見える問題に対する（単純な、多分、私にはわかりませんが）解決策を提案しているだけです。 しかし、私に関する限り、私自身の小さなニーズのために、Electronの現在の状態を本当に気にしません。 電子は素晴らしいです、私はそれをさらに良くする方法を考えています。

Electronは最高のフレームワークではありません。

@ fab1an 、人々が何を必要としているか

ランタイムは以前に提案され、議論されており、まだオープンな議論です。 しかし、これは言うのが簡単なことの1つです。 ご覧のとおり、すべての人が同じページにアクセスしたり、本番環境で確実に機能するように適切に作業を開始する方法を理解したりできるわけではありません。 あなたが議論に貢献したり、それを始めるのを手伝ったりできると思うなら、私は誰も追加の助けを気にしないと思います。

私を含む多くの開発者は、40メガのダウンロードを出し、より小さなデルタ更新を使用してそれを更新することにかなり満足しています。 今日の人々は40メガのプログラムをダウンロードするのに問題はありません。 そして、数メガファイルの小さなプログラムでさえ、40メガ（2ギガ）をダウンロードしてインストールする可能性があり、誰も問題を抱えていないようです。 それと。 ランタイムオプションが利用可能であったとしても、ユーザーがそれを持っていない可能性があり、とにかくプロジェクトを実行するために40以上のメガバイトをダウンロードする必要があります。

この警告があなたのお茶ではない場合は、必要に応じて別のオプションを検討してください。 率直に言って、達成したい目標や条件を達成するためにテクノロジーを排除しなければならない場合があります。 しかし、これによってElectronが悪いテクノロジーになったり、他の多くの人が使用できなくなったりすることはありません。 電子はすべての解決策を解決することを意図していません。 そして、それは現実的には決してありません。

@baconbradあなたのコメントが私をターゲットにしているのなら、理由はわかりません。私は何度かはっきりと言ったのですが、私はそれなりにかなり満足しており、Electronはまさに私の（特定の）ニーズに適したテクノロジーでした。

私は、パッケージのサイズについて多くの人がいたるところに不満を言っているのを見ただけで、その問題に対する（再び素朴な）解決策を提供しているだけで、それは私にとって理想的だと思われました。 しかし、私は非常に誤解されている可能性があり、いずれにせよ、将来のニーズにElectronを使用することを完全に妨げることはありません:)

ランタイムオプションが利用可能であったとしても、ユーザーがそれを持っていない可能性があり、とにかくプロジェクトを実行するために40以上のメガバイトをダウンロードする必要があります。

ええ、でも私はパリ中心部でさえ、インターネット接続が5Mbpsしかない人をたくさん知っています。それらの人にとって、アプリごとに40MB（つまり、320Mb）を節約するということは、アプリが更新されるたびに数分節約することを意味します（インターネット接続が使用されていない場合、最初のインストールだけでなく、更新ごとに40MBが使用されることを忘れないでください。

特にノートブックの場合、RAMの節約も考慮されていません。 繰り返しになりますが、私は32GBのRAMを備えた比較的優れたマシンを持っているので、個人的には心配していませんが、ここでは自分自身についてではなく、不平を言っている人々について考えており、解決策を見つけたいと思っています。

大事なことを言い忘れましたが、あなたは良い接続を持っているかもしれません、そして私もそうです（あなたが喜ばせれば超高速のものです！:)）、そして私たちは両方とも16または32または64GBのRAMを持っているかもしれません、それがあなた（あなた自身）がいない理由ですアップデートごとに40MBをダウンロードしてもかまいませんが、ユーザーはどうでしょうか（アプリを他の人に配布する場合）。

とにかく、私はこれについて戦うつもりはありません、私は助けを求めていただけでした、そして私が言ったように私はそれなりにかなり幸せです、そして私は出席することがたくさんあります。

誰かが私が解決策を考えるのを手伝うことができると思うなら、私は手を貸して喜んでいるでしょう、しかしそうでなければ私は仕事に戻ります:)

乾杯、

より多くの依存関係をdevDependenciesに移動するときに私が見たもののひとつは、それを構築するためにより多くの時間を必要とすることです。

`` ``
✔メインプロセスの構築

• レンダラープロセスの構築
  `` ``

「レンダラープロセスの構築」に多くの時間を費やし、アニメーションアイコンがクラッシュするように停止しましたが、クラッシュしませんでした。 次に、レンダラーレポートから203778msが表示されます。

devDependenciesを依存関係に戻すと、ビルド時間は再び正常になりますが、アプリは大きくなります。

ビルド中にエラーが発生していなければ、問題ないということですか？

@karimhossenbuxこれは私にとっては正常なことです。 electron-packagerには、すべての依存関係を調べて、依存関係が存在するかどうかを判断するウォーク関数があります。 ネストされた代わりに新しいフラットスタイルの依存関係を使用すると、不要な依存関係を判別するのにはるかに長い時間がかかります。 私の知る限り、余分なビルド時間を回避する方法はありません。

@baconbradありがとうございます！ electron-builderを使用していますが、同じように機能すると思います。

ユーザーがアプリを初めて実行するときに、ソースのみを含み、他のソースをダウンロードする（現在のオペレーティングシステムユーザーが実行している場合にのみ必要）電子パッケージビルダーはありますか？ 配布が簡単になり、アプリのサイズを大幅に縮小できます。

電子、「ERE」ルートには行かないでください。 はい、私はあなたが肥大化していることを知っていますが、人々が私のアプリケーションをダウンロードする方法が大好きで、depsのインストール、ランタイム環境の更新、または2003年頃に私たちが取り除いたと思っていたナンセンスのいずれかをいじくり回す必要なしにうまく動作します。

まあ、バンドルをダウンロードすることはまだオプションです。 何も文句を言うことはありません
ここについて:)

Leven。 25の舞2018 21：03à、ルークPighetti [email protected] A
écrit：

電子、「ERE」ルートには行かないでください。 はい、私はあなたが肥大化していることを知っています、
しかし、私は人々が私のアプリケーションをダウンロードする方法が大好きで、それはうまく動作します
depsのインストール、ランタイムの更新に煩わされることなく
環境、または私たちが約を取り除いたと私が思ったそのナンセンスのいずれか
2003年。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/electron/electron/issues/2003#issuecomment-392151709 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AApUIBjAeVZ7T4SKo8LyW6RT65XnpiKgks5t2FWfgaJpZM4FGGer
。

マイクロソフトのエンジニアがElectronを改善するのを待っています。
https://news.ycombinator.com/item?id=17229973

マイクロソフトのエンジニアがElectronを改善するのを待っています。
https://news.ycombinator.com/item?id=17229973

@zcmgyu Microsoftは、VS CodeでElectronを使い始めてから、数年前から開発者を雇ってElectronに取り組んできました。 そして、彼らは最大の貢献者の一部であり、それをかなり改善しました。

アプリケーションが100MBを超える場合は、
exeファイルにnode_modulesフォルダーのかなりの部分が含まれている可能性があります。
依存関係のpackage.jsonで宣言されたものはすべて、最終的な実行可能ファイルにインポートされて戻されることに注意してください。
（検証は非常に簡単です：実行可能ファイルを逆コンパイルするだけで十分です）
したがって、依存関係（electron-log、electron-updater）に必須のライブラリのみを定義し、devDependenciesに他のすべてのライブラリを追加することを忘れないでください。

その場合、アプリは「50MBのみ」になります...

私のアプリは小さいです-これがレポです。 最新の実験バージョンの重量は約700mbです
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

私もこれについて疑問に思っています。 これが私のエレクトロンアプリのサイズです：

  osx - 117.3 mb

linux32-60.3 mb
linux64-55.2 mb
ia32に勝つ-47.8mb
x64で勝つ-66.2mb
ありがとう！

すばらしい！ 電子アプリを非常に小さいサイズに縮小する方法について教えてください。