Electron: Ukuran bundel aplikasi yang diharapkan?

Itu ukuran yang diharapkan, tidak ada cara untuk membuatnya lebih kecil.

Apakah itu benar-benar diharapkan menjadi sebesar itu? bundel windows dan linux build saya jauh lebih kecil, dan melihat ke folder Electron Framework, ada tiga salinan file Electon Framework, masing-masing satu:

ContentsFrameworksElectron Framework.framework
ContentsFrameworksElectron Framework.frameworkVersionsA
ContentsFrameworksElectron Framework.frameworkVersionsCurrent

Apakah ini seharusnya tautan simbolik?

Seberapa kecil build Windows dan Linux?

Saya juga bertanya-tanya tentang ini. Berikut adalah ukuran untuk aplikasi elektron saya:

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

Terima kasih!

Apakah ada rencana untuk mencoba mengurangi ukuran kerangka kerja di rilis mendatang? Hal ini membuat sulit untuk membenarkan penggunaan Electron untuk aplikasi kecil (di mana ukuran aplikasi itu sendiri akan dikerdilkan oleh ukuran Electron).

Saya dapat mengonfirmasi bahwa bundel aplikasi elektron saya berukuran hampir sama dengan @davefedele.

Anda dapat meng-zip aplikasi Anda dan jika Anda menggunakan electron-packager Anda dapat mengabaikan beberapa modul simpul yang tidak Anda perlukan saat aplikasi berjalan, ini membuatnya sedikit lebih kecil. Misalnya saya memiliki aplikasi Electron zip 37MB (Catatan versi Windows jauh lebih besar karena berisi salinan Git).

Tetapi Electron akan selalu memiliki sebagian besar Chrome di dalamnya sehingga hanya ada begitu banyak yang bisa dilakukan. Elektron itu sendiri sekarang adalah ~33MB.

OS X terkompresi berukuran sama dengan platform lain yang mungkin berarti bahwa aplikasi yang Anda gunakan untuk mengukur ukuran mungkin salah mengartikan symlink?

Dalam kasus saya, saya menggunakan elektron-boilerplate yang tidak menggunakan electron-packager dan folder aplikasi elektron saya di-zip dengan skrip python dan didistribusikan melalui aws s3. Jadi pertama saya adalah bahwa symlink tidak dihormati saat mengompresi (daripada ukuran file yang disalahartikan).

Saya harus memeriksanya, apakah ada daftar symlink yang ada? Saya memiliki akses yang sangat terbatas ke komputer mac (saya menggunakan server CI untuk mengemas aplikasi saya untuk setiap platform).

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

Saya akhirnya bisa melihat ini kemarin, dan memang masalah saya disebabkan oleh symlink yang tidak dipertahankan. Jadi ukuran aplikasi saya menyusut drastis dari ~110Mbs, menjadi ~45Mbs.

@carlosperate Bisakah Anda menjelaskan bagaimana Anda memperbaiki symlink Anda?

Yah, penting untuk ditekankan bahwa saya tidak menggunakan electron-packager . Saya memiliki "skrip build" python (skrip yang sama berjalan di windows, linux dan os x) yang akan membangun hal-hal lain yang independen untuk aplikasi elektron saya, kemudian jika berjalan di mac itu akan menyalin semuanya ke direktori bundel aplikasi OS X umum, dan akhirnya zip semuanya ke dalam satu file.

Jadi, dalam kasus khusus saya ada dua masalah dengan skrip saya, saya menyalin file elektron tanpa menghormati symlink (sangat mudah diperbaiki), dan kemudian modul zipfile di Python juga tidak menghormati symlink, yang ternyata tidak semudah yang saya harapkan. Jika Anda mencari solusi untuk masalah tersebut, Anda akan menemukan beberapa artikel dengan implementasi aneh yang lebih dekat dengan keajaiban daripada penjelasan nyata, jadi setelah beberapa waktu tidak berhasil mencoba membuatnya berfungsi, saya akhirnya hanya menjalankan subproses yang mengeksekusi os x zip Perintah CLI dengan flag yang diperlukan untuk menghormati symlink.

FWIW, saat membuat zip di Linux untuk distribusi ke OS X, Anda harus menggunakan parameter -y untuk menangani symlink dengan benar:

$ zip -r -y app.zip app

Apa yang telah dilakukan #SLACK? Mengapa aplikasi mereka sangat kecil?
File arsip zip berukuran 24.6 MB.

Versi Windows dan linux kurang lebih seperti yang saya harapkan, saya bertanya-tanya bagaimana mereka membuat versi OSX mereka begitu kecil.

Terakhir saya memeriksa slack menggunakan MacGap untuk sisi mac

http://electron.atom.io/#built -on-electron Slack ada dalam daftar.

Ya, aplikasi Windows dan Linux Slack dibangun di atas Electron, tetapi aplikasi Mac menggunakan MacGap.

@joshaber saya pikir Anda benar. Aplikasi Slack mac hanya ~36 MB.

Apakah kalian tahu jika Electron memiliki rencana untuk mengurangi ukuran bundel akhir? Itu akan luar biasa.

Apakah kalian tahu jika Electron memiliki rencana untuk mengurangi ukuran bundel akhir? Itu akan luar biasa.

Hanya ada begitu banyak yang dapat Anda ambil dari Chromium, Node.js, V8, dll dan masih memiliki produk yang berfungsi. Sayangnya karena semuanya ditambal agar berfungsi, itu tidak semudah membuatnya menggunakan versi mandiri masing-masing untuk mengurangi ukuran. Saya yakin tim Electron menginginkan ukuran yang lebih kecil. Tapi Anda tidak bisa merencanakan dan mewujudkannya. Terlalu pedas pada keseluruhan proyek untuk berpikir Anda dapat menghapus bahkan 10-20 MB kode dan sumber daya dan mengharapkan semuanya berjalan stabil.

Benar sekali @baconface... Satu hal yang telah membantu saya di sini: Saya meletakkan modul-modul seperti electron-prebuilt, electron-builder dan electron-packager dan semua ketergantungannya di folder "app". Memotongnya dari package.json aplikasi dan membangun lagi menghemat banyak ukuran. Saya menggunakan struktur two-package.json dari electron-builder.

@leonelcbraz Jangan ragu untuk meminjam atau mendapatkan ide dari regex abaikan saya untuk electron-packager . Saya membuat file yang dapat dieksekusi di direktori bin, memiliki direktori src untuk file sumber yang tidak diminifikasi, menggunakan Grunt untuk membangun, dan memiliki hal-hal lain yang tidak saya perlukan di sana. Jika saya mengerjakan sebuah proyek, saya tidak perlu menggunakan konteks simpul, saya hanya menetapkan nodeIntegration ke false dan mengabaikan seluruh direktori node_modules. Ini secara drastis mengurangi ukuran distribusi saya.

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

Selain itu tidak perlu menggunakan struktur two-package.json. NPM mendukung dependensi pengembang. Anda dapat menginstalnya melalui npm install <package name> --save-dev . Anda kemudian akan melihat di package.json Anda memiliki dependencies dan devDependencies dengan dependensi Anda terpisah dengan rapi. Memodifikasi regex abaikan untuk electron-packager seperti yang saya lakukan di atas, Anda dapat sepenuhnya mengisolasinya dari aplikasi Anda namun bekerja di lingkungan node.js normal.

Sunting: Ini bahkan lebih mudah dari ini!

Kedengarannya bagus. Terima kasih sudah berbagi :)

Slack sekarang memiliki beta Elektron dari klien Mac. Biner Mac lama (menggunakan MacGap) adalah 36MB pada disk. Biner Mac baru (menggunakan Electron) adalah 175MB. 124MB di antaranya adalah Kerangka Elektron.

@NelsonMinar Ini menyebalkan, kawan. Perlu melakukan sesuatu dengan ukuran aplikasi.

Sepakat.

Menggunakan @baconface abaikan regex banyak membantu dengan mengurangi ukuran aplikasi, saya juga secara manual mengabaikan lebih banyak node_modules yang ada di sana dan aplikasi saya dapat berjalan dengan baik tanpanya, yang membuat saya menjadi sekitar 50MB dari total ukuran aplikasi Mac dan sekitar 60MB untuk Windows.

@pierreraii Senang itu membantu. Catatan penting adalah NPM3 mengubah cara kerja direktori node_module . Akibatnya trik ini mungkin tidak bekerja sesuai harapan Anda. Anda dapat menurunkan versi NPM ke versi 2 menggunakan npm i npm<strong i="7">@2</strong> -g .

Di masa depan solusi kami untuk proyek kami di tempat kerja menggunakan NPM3 tetapi menempatkan semua yang tidak kami inginkan dikirimkan sebagai ketergantungan pengembang. Kami memasang alat pembuatan Elektron kami secara global berlawanan dengan tingkat proyek. Kemudian lakukan instalasi hanya modul yang diperlukan dengan npm install --only=production . Namun ini tidak ideal untuk proyek sumber terbuka tetapi berfungsi untuk kantor kami. Sangat disayangkan kita harus memiliki pengaturan yang aneh seperti ini tetapi diragukan NPM akan pernah dirancang dengan Electron dalam pikiran karena itu hanya blip dalam ekosistem NPM.

ya, memberi tahu pengembang web untuk menangani elektron di atas ternyata hampir tidak mungkin. hanya memikirkan env yang dapat menjadi keduanya ... saat ini saya mendasarkan aplikasi elektron saya pada server yang digunakan sebelumnya, karena mereka dapat sebelum dan untuk semua yang lain, idealnya berbagi dependensi yang sama. jika asar bisa menjadi fs pengguna nyata, maka saya akan mempertimbangkan masalah ukuran dan penyalinan diselesaikan, terutama dengan ekstensi asli

@baconface Anda tidak perlu khawatir tentang semua itu. Cukup instal dependensi Anda seperti biasa (prod deps di dependencies dan dev deps di devDependencies ) dan kemudian selama fase pengemasan ( electron-packager melakukan ini untuk Anda) cukup salin folder aplikasi Anda ke direktori temp dan jalankan.

npm prune --production

Itu akan menghancurkan semua dependensi dev terlepas dari versi NPM Anda yang menghasilkan ukuran seminimal mungkin.

Anda bisa mendapatkan 40-80+ % lebih banyak lagi yang dihapus daripada hanya dengan --production

Anda bisa mendapatkan 40-80+ % lebih banyak lagi yang dihapus daripada hanya dengan --production

Jika demikian, dependensi Anda tidak dikonfigurasi dengan benar, jika Anda perlu menghapus modul dan prune --production tidak menghapusnya, berarti modul tersebut telah dikenali sebagai dependensi produksi. Memindahkannya ke devDependencies akan mengakibatkan penghapusannya.

oh maaf, lupa mengatakan: jika Anda membuat topeng file yang menghapus readme, lisensi, ... dan node-gyp saja menghasilkan 100 kali lipat lebih

@xblox Saya hanya bisa membayangkan readmes/lisensi dan semacamnya seperti beberapa kilobyte, trik baru yang keren adalah menjalankan yarn clean yang secara otomatis menghapus hal-hal ini untuk Anda.

@MarshallOfSound Anda akan terkejut, terutama ketika Anda menggunakan modul asli. Banyak sampah berserakan. Pendekatan yarn clean mungkin bagus

@MarshallOfSound melakukan topeng file Anda

@MarshallOfSound, @paulcbetts: setelah bermain dengan yarn clean : membersihkan hanya sekitar 70% dari apa yang mungkin dengan file masker disebutkan

Jika kita hanya ingin menulis aplikasi hello world tanpa ketergantungan modul node, mengapa packager masih membengkokkan semuanya? Solusi mutakhir adalah dengan menggunakan yarn clean , bukan?

Node_modules saya 40 MB dan elektron 140 MB

Menggunakan pembuat elektron dan file ini glob saya mendapatkan sekitar 80% pada aplikasi desktop saya

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

Masalahnya adalah itu sangat bergantung pada modul yang Anda gunakan, yang membuatnya sulit untuk dipertahankan!

@farfromrefug hati-hati mengirim aplikasi Anda jika Anda menggunakan

@OmgImAlexis Sebenarnya Anda benar, saya harus menyimpan file Lisensi. Terima kasih!

Hanya kepala ke atas. electron-packager cukup pintar untuk membersihkan dependensi yang terdaftar dalam devDependencies . Jadi saya memindahkan sebagian besar paket saya ke sana dan menggabungkan skrip yang saya gunakan dalam satu file JS menggunakan Grunt. Jadi sekarang regex saya untuk abaikan terlihat seperti ini "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|build.js)" . Memberi saya hasil yang sama tetapi jauh lebih mudah dan saya tidak perlu menambahkan jalur ketergantungan secara manual ke regex saya. Bahkan bekerja dengan cara Benang menyimpan dependensi.

Saya baru-baru ini mengkloning proyek contoh untuk tujuan pembelajaran dari https://github.com/electron/simple-samples.git . Saya telah membuat aplikasi monitor aktivitas win32 x64 yang ada di dalam folder kloning dengan perintah berikut:
electron-packager C:userlearningnodeclonedAppsimple-samplesactivity-monitor cpu --platform=win32 --arch=x64 --ignore="node_modules"

Saya bertanya-tanya ukuran bundel 132 Mb hanya untuk aplikasi sederhana.
Apakah ada cara untuk mengurangi ukuran bundel?

Saya akan menyarankan untuk menggunakan UPX pada executable Anda, yang merupakan cross-platform, mendukung banyak arsitektur dan sangat mudah digunakan, tetapi sayangnya tampaknya tim Electron memilih untuk tidak tunduk pada hal ini.
(Sudah diminta sebelumnya: https://github.com/electron/electron/issues/5506)

Jika tidak, pengujian saya bekerja dengan baik dengan mengompresi NW.js dengan UPX (~60% lebih rendah dalam ukuran akhir) meskipun saya tidak mencoba jika masih berfungsi dengan versi terbaru...
Jadi jika ukuran itu penting, mungkin Anda bisa fokus mengembangkan dengan yang ini saja?

Saya bisa mendapatkan ukuran distribusi OSX zip saya menjadi 52MB dengan memindahkan electron dan hampir semua paket non-runtime lainnya ke devDependencies di package.json , menjalankan rm -rf node_modules dan kemudian npm install --production .

Saat mengemas aplikasi, electron-packager akan mengeluhkan hilangnya electron ketergantungan dalam node_modules proyek. Anda dapat mengatasinya dengan memberikan flag berikut ke electron-packager :

--electron-version=1.7.11

Pengganti 1.7.11 dengan yang diinginkan Anda electron-packager versi.

@eladnava Terima kasih telah memberikan informasi. Saya akan memeriksa langkah-langkah yang diberikan oleh Anda. Saat saya convert aplikasi ke dmg ukurannya 53 MB.

Saya tidak tahu/tidak membaca semua pesan sebelumnya, jadi tolong beri tahu saya jika sudah dikatakan.

Apakah mungkin untuk memisahkan kerangka Electron itu sendiri dan hanya mengirimkan aplikasi?

Sejauh yang saya mengerti, cara pengiriman aplikasi Electron adalah fw disertakan. Kedengarannya seperti mengirimkan aplikasi Java dengan JRE disertakan di dalamnya.

Apakah mungkin untuk menginstal kerangka Electron ke OS sehingga semua aplikasi yang dapat menggunakan versi itu akan digunakan?

@eladnava Anda menyadari bahwa Aplikasi Anda tidak akan berjalan jika elektron tidak diinstal pada mesin target?

@fab1an : Saya pikir @yasinaydin mengerti itu. Dia menginginkan runtime umum Electron yang dapat diinstal pengguna untuk semua aplikasi yang menggunakan Electron. Ini sudah dibahas di elektron/elektron#673, saat ini tanpa resolusi.

@js-choi @fab1an Saya tidak sepenuhnya yakin bagaimana cara kerjanya, tetapi saya merasa Electron sudah disertakan dalam paket electron-packager , dalam Electron Framework.framework yang disertakan dalam aplikasi yang dikemas.

Oleh karena itu, tidak ada alasan untuk juga menggabungkan electron dalam node_modules aplikasi Anda. Juga, paket npm electron perlu diinstal pada mesin target agar pendekatan saya berfungsi.

electrino mampu membuat aplikasi Electron 115 MB menjadi hanya 167 kB menggunakan teknologi mereka. Saya pikir teknologi ini harus diintegrasikan ke dalam elektron, aplikasi hello world 100MB bukan ukuran normal untuk menampilkan "Hello World" :+1:

@spaceywolfi Karena Electrino tidak benar-benar menjalankan mesin Chrome / V8 untuk merender aplikasi Anda, tetapi menggunakan mesin browser web asli OSX (WebKit), Anda tidak dapat benar-benar mengambil aplikasi Electron dan membangunnya dengan Electrino, terutama jika Anda menggunakan API Elektron, karena tidak tersedia di sana. Setidaknya belum.

Anda dapat mencoba menggunakan trik yang saya sebutkan untuk mendapatkan ukuran biner dasar hingga ~50MB.

@eladnava terima kasih sudah menjelaskan!

@eladnava

Saya tidak sepenuhnya yakin bagaimana cara kerjanya, tetapi saya merasa Electron sudah dibundel sebelumnya dalam paket elektron, di dalam Kerangka Kerja Elektron. Kerangka kerja yang disertakan dalam aplikasi yang dikemas.

Oleh karena itu, tidak ada alasan untuk juga menggabungkan elektron dalam node_modules aplikasi Anda. pendekatan untuk bekerja.

Saya memiliki electron dan electron-packager di devDependencies . Dengan cara ini saya dapat menetapkan electron ./dist/js/main.js ke skrip di package.json . Jadi menjalankan npm run launch misalnya akan dengan cepat meluncurkan instance aplikasi Electron saya yang siap diuji tanpa paket. Selain itu electron-packager akan menggunakan versi yang terdaftar untuk electron sehingga versi paket Anda sama dengan versi pengujian Electron Anda. Itu juga harus menghapus electron dan electron-packager dari output secara otomatis juga.

@baconbrad

Terima kasih atas tip Anda. Saya akhirnya menginstal electron dan electron-packager secara global untuk menghindari mereka dikemas ke dalam folder node_modules biner final. Saya menemukan bahwa electron-packager tidak menghapus dependensi ini secara otomatis dari biner terakhir, yang menghasilkan ukuran biner ~100MB untuk saya. Setelah menginstal dua paket ini secara global, ukuran biner turun menjadi ~50MB.

@eladnava Ini kemungkinan terjadi karena Anda memilikinya sebagai ketergantungan dan bukan sebagai ketergantungan pengembang. Jika Anda menggunakan npm install packagename --save-dev ini akan menyimpannya di area yang tepat dari package.json . Ini akan muncul di folder node_modules tetapi akan dihapus setelah dikemas.

@baconbrad

Ini sangat mungkin. Tapi saya pikir karena versi npm menginstal semua dependensi dependensi Anda di folder node_modules/ proyek root, ini mungkin telah dibundel oleh electron-packager ke dalam biner final .

Tahukah Anda jika electron-packager cukup pintar untuk menghilangkan dependensi devDependencies ' itu?

@eladnava

Tahukah Anda jika paket elektron cukup pintar untuk menghilangkan dependensi devDependencies itu?

Dapat mengonfirmasi bahwa itu menghilangkan dependensi devDependencies . Bahkan jika Anda menggunakan NPM atau Yarn versi terbaru.

Anda juga harus menggunakan sistem build seperti Gulp atau Grunt untuk menggabungkan dependensi front-end dan membuatnya terdaftar di devDependencies juga. Ini karena mereka mungkin dikirimkan dengan file sumber tambahan atau devDependencies . Satu-satunya waktu saya memiliki sesuatu di dependencies adalah karena saya benar-benar perlu mengirimkannya. Skrip Anda masih ingin dijalankan dalam konteks simpul sehingga Anda perlu memanggil window.module = module; module = undefined; sebelum memuat skrip yang dibundel dalam konteks browser. Saya kemudian memastikan bahwa pembuat paket saya memiliki ini di opsi abaikan "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)" . Melakukan semua langkah ini pada dasarnya menghilangkan ketergantungan yang berlebihan atau salah memasukkan file sumber atau folder build.

@baconbrad

Trims untuk tipsnya sobat!

Halo kawan-kawan,

Untuk mengurangi ukuran aplikasi secara drastis untuk semua orang, menghemat bandwidth untuk semua orang, membuat proses pembuatan lebih mudah untuk semua orang, dll. optimasi/pemikiran harus dilakukan secara berbeda daripada hanya mengabaikan beberapa node_modules.

Bagaimana dengan menggunakan ide yang sama yang telah berhasil digunakan oleh aplikasi Java dan Java selama beberapa dekade: memiliki ketergantungan pada "JRE" (yang akan menjadi "ERE" dalam kasus kami).

Dengan begitu, ERE akan diinstal secara global pada mesin untuk aplikasi pertama yang membutuhkannya (proses yang membutuhkan ERE dapat diotomatiskan oleh penginstal aplikasi untuk setiap platform), dan kemudian setiap aplikasi baru hanya akan menggunakan ERE yang sudah ada ini. .

ERE akan membutuhkan fitur pembaruan otomatis dan kompatibilitas mundur (tanpa bcb!) Agar ini berfungsi, tetapi saya cukup yakin ini sepele.

Kemudian, setiap aplikasi Electron akan berbobot seperti beberapa MB saja. Menghemat waktu pengguna. Menghemat waktu dan bandwidth pengembang dan membangun kompleksitas.

Apakah sudah diusulkan sebelumnya? Jika demikian, lalu bagaimana? Saya pikir ini adalah satu-satunya dan cara terbaik untuk pergi.

@RenaudParis Saya mengusulkannya sebelumnya dan mungkin beberapa lagi, tapi sejauh ini saya belum mendengar ada pekerjaan serius.

@yasinaydin Saya pikir juga, orang-orang pasti sudah memikirkannya sebelumnya.

Nah, ada masukan dari tim dev? @zcbenz Ini akan membuat begitu banyak orang senang, dan akan membuat Electron tahan terhadap masa depan (karena mari kita hadapi itu: menyematkan dua kerangka kerja di dalam masing-masing dan setiap aplikasi secara serius membatasi penggunaan untuk aplikasi yang lebih kecil, ini adalah kata-kata kasar biasa yang telah terjadi selama bertahun-tahun)

Bukankah JRE adalah contoh yang bagus untuk diikuti di sini?

@RenaudParis dan @yasinaydin , ada banyak alasan mengapa pemasangan elektron global tidak akan pernah terjadi.

Pertama, dari semua aplikasi elektron produksi di luar sana, mungkin ada 20+ versi elektron yang berbeda yang digunakan. Versi mana yang akan Anda pilih untuk dimiliki secara global? Ini terfragmentasi seperti ini karena elektron memiliki siklus rilis yang cepat dan pengembang menginginkan akses ke fitur Chrome terbaru.

Aplikasi kami hanya diuji dengan satu versi elektron dan demi unduhan 40MB, mengapa kami menanggung risiko dan biaya dukungan untuk memungkinkannya berjalan pada versi acak lain yang belum diuji?

buat proses pembuatan lebih mudah untuk semua orang

Banyak aplikasi elektron menggunakan modul asli yang dalam banyak kasus harus dibuat dengan versi spesifik dari elektron yang digunakan. Bagaimana Anda memecahkan masalah ini?

Jangan ragu untuk membuat elektron versi global yang dapat digunakan pengembang, tetapi saya pikir Anda akan menemukan bahwa hampir tidak ada orang yang akan menggunakannya karena alasan di atas!

@timfish
there are so many reasons having a global install of electron will never happen.
Kedengarannya seperti ini: https://www.pcworld.com/article/155984/worst_tech_predictions.html

Karena Node/v8 atau binari elektron tidak terlalu besar, ERE global dapat mengunduh komponen yang hilang untuk digunakan sekali, jika diperlukan. Juga beberapa logika bundel dapat diimplementasikan untuk ERE global ini, seperti Node.js 9.x alih-alih memisahkan Node.js 9.0, 9.1 dll.

Entahlah, tapi menurutku itu bukan sikap untuk melakukan sesuatu... "Oh tidak bisa. Oh tidak mungkin. Tidak masuk akal." Sebaliknya seharusnya "Bagaimana kita bisa menyelesaikan/menyelesaikan x ini?"

@timfish ini adalah berita sedih... Saya pribadi tidak terlalu peduli dengan file 40MB, tetapi 120MB (seperti yang saya dengar) agak terlalu banyak untuk hello world.

Pertama, dari semua aplikasi elektron produksi di luar sana, mungkin ada 20+ versi elektron yang berbeda yang digunakan. Versi mana yang akan Anda pilih untuk dimiliki secara global?

Seperti yang saya katakan, kompatibilitas mundur akan diperlukan.

pengembang menginginkan akses ke fitur Chrome terbaru

Oleh karena itu peningkatan progresif... Benar? Bagaimanapun, bahkan peningkatan progresif tidak wajib jika aplikasi dapat memerlukan versi ERE tertentu, yang akan memicu pembaruan ERE global.

Bagaimana Anda memecahkan masalah ini?

Jika beberapa orang memerlukan modul yang dikompilasi secara khusus, mereka bebas untuk menyematkan versi modul kustom mereka sendiri (yang bagaimanapun juga tidak akan tersedia di dalam ERE) dan menentukan versi minimum ERE. Jika ERE diperbarui ke versi yang lebih baru, saya kira ada 2 solusi yang jelas: apakah mereka memperbarui modul mereka (sama seperti dengan dependensi di Node hari ini) atau kami juga dapat mengizinkan beberapa versi global ERE (sama seperti JRE). Saya pikir ini bukan masalah.

elektron memiliki siklus pelepasan yang cepat

Ini bagus, tidak diragukan lagi di sini. Tapi mungkin orang bisa bertahan dengan rilis bulanan, sehingga membatasi jumlah versi ERE.

Jangan ragu untuk membuat versi global

Ya... Tidak akan melakukan itu. Saya tidak memiliki keterampilan, tetapi saya akan melakukannya jika saya memilikinya.

Saya hanya dapat menawarkan saran yang saya anggap relevan, dan membiarkan para ahli melakukan pekerjaan mereka: apakah mereka memberi tahu saya bahwa saya bodoh dengan saran saya (yang mungkin memang demikian), atau mereka menganggap itu mungkin mengarah pada sesuatu yang baik. . Apa pun :)

Saya masih berpikir ERE global akan menjadi solusi terbaik, bahkan jika itu berarti memiliki banyak ERE untuk berbagai kebutuhan aplikasi yang berbeda di luar sana. Tapi, sekali lagi, ini hanya ide saya dari membandingkan dengan JRE.

@RenaudParis

ini adalah berita sedih... Saya pribadi tidak terlalu peduli dengan file 40MB, tetapi 120MB (seperti yang saya dengar) agak terlalu banyak untuk hello world.

120MB tidak terkompresi, jika Anda mengompresnya sekitar 40MB. Misalnya, VSCode 64-bit untuk instalasi Windows EXE adalah sekitar 42,8 MB.

Secara pribadi, sebagai pengguna, saya selalu lebih suka memiliki aplikasi mandiri tanpa perlu mengelola JRE global (atau ERE) bahkan jika saya harus mengunduh 200MB daripada 10MB.

Bukan hanya 120mb, saya membuat aplikasi web sederhana yang ~1mb di server web tetapi ~300mb sebagai aplikasi Electron di OS X

Plus, ini menjadi lebih penting ketika ada banyak aplikasi Electron yang berjalan di mesin yang sama.
Maka itu akan menjadi 10 kali, 20 kali lebih besar.
Sekarang ada beberapa aplikasi standar di komputer yang dibuat dengan Electron seperti Slack, VSCode dll. Dan ada proyek yang lebih besar seperti NodeOS.

Node.js memiliki >500 ribu modul. Jika Electron menjadi lebih baik & lebih cepat & lebih populer & lebih kecil, akan ada lebih banyak aplikasi di desktop, dengan GB file Electron yang tidak perlu.

Elektron bukanlah kerangka kerja terbaik.

Saya lebih suka membagi bagian yang tidak dibutuhkan dari kerangka kerja Chrome seperti Flash dll.

@yasinaydin

1mb di server web tetapi ~300mb sebagai aplikasi Electron di OS X

Anda perlu membersihkan aplikasi Anda sebelum distribusi (petunjuk: periksa node_modules Anda). Misalnya, VSCode pada Windows adalah 228MB setelah instalasi (instalasi yang dapat diunduh hanya 42,8MB).

Tapi, ukuran instalasi hanya satu masalah, Masalah lainnya adalah berapa banyak RAM yang digunakan aplikasi dan waktu peluncuran. Menurut pengalaman saya, begitu aplikasi diluncurkan, kecepatan aplikasi tidak menjadi masalah.

Elektron tidak cocok untuk aplikasi kecil, tetapi untuk aplikasi besar seperti VSCode berfungsi.

Masalah lainnya adalah berapa banyak aplikasi RAM yang digunakan dan waktu peluncuran

@mvladic tidakkah menurut Anda justru itu adalah dua masalah lagi yang akan diperbaiki oleh ERE? Sudah dimuat dan dibagikan di antara aplikasi, dan semuanya.

Oke, mungkin orang tidak menjalankan 10 aplikasi Electron secara bersamaan... Tapi mungkin mereka akan melakukannya! Memfaktorkan dependensi sebanyak mungkin adalah penting.

Saya mendapatkan bahwa Electron pertama kali diluncurkan sebagai POC, dan kemudian membutuhkan rilis yang sangat sering untuk menyenangkan para pengembang. Tapi mungkin sekarang Electron lebih matang, beberapa tindakan harus diambil untuk memastikan {load time, ram usage, download size} yang terbaik.

Sekali lagi, saya hanya mengusulkan solusi (mungkin naif, saya tidak tahu) untuk masalah yang tampaknya diomel oleh pengguna Electron sejak awal. Tapi sejauh yang saya ketahui, saya benar-benar tidak keberatan dengan keadaan Electron saat ini untuk kebutuhan kecil saya sendiri. Elektron itu hebat, saya hanya memikirkan cara untuk membuatnya lebih baik.

Elektron bukanlah kerangka kerja terbaik.

@fab1an , tergantung kebutuhan orang. Bagi saya, ini sangat sesuai dengan kebutuhan saya, karena saya tidak yakin bahwa PWA cukup matang. Tapi sekali lagi mungkin untuk orang lain Qt akan lebih cocok, Anda benar tentang itu.

Sebuah runtime telah diusulkan dan didiskusikan sebelumnya dan masih merupakan diskusi terbuka . Tapi ini adalah salah satu hal yang lebih mudah diucapkan daripada dilakukan. Seperti yang Anda lihat, tidak semua orang dapat memahami halaman yang sama atau mencari cara untuk melakukannya dengan benar di mana ia akan bekerja dengan andal dalam produksi. Jika Anda pikir Anda dapat berkontribusi pada diskusi atau membantu memulainya, saya tidak berpikir siapa pun akan keberatan dengan bantuan tambahan.

Banyak pengembang termasuk saya cukup senang dengan mengunduh 40 mcg dan memperbaruinya menggunakan pembaruan delta yang lebih kecil. Orang-orang saat ini tidak memiliki masalah mengunduh program 40 mcg. Dan bahkan program kecil di luar sana yang memiliki beberapa file mega mungkin mengunduh dan menginstal 40 MB - 2 gigs dan sepertinya tidak ada yang memiliki masalah. dengan itu. Bahkan jika opsi runtime tersedia, kemungkinan pengguna tidak akan memilikinya dan harus mengunduh 40+ MB untuk menjalankan proyek Anda.

Jika peringatan ini bukan secangkir teh Anda, lihat opsi lain jika diperlukan. Saya tidak bermaksud terus terang, terkadang Anda harus menghilangkan teknologi untuk memenuhi tujuan dan kondisi yang ingin Anda penuhi. Tapi ini tidak membuat Electron menjadi teknologi yang buruk atau membuatnya tidak dapat digunakan oleh banyak orang lainnya. Elektron tidak dimaksudkan untuk memecahkan setiap solusi. Dan secara realistis tidak akan pernah.

@baconbrad jika komentar Anda menargetkan saya, saya tidak mengerti mengapa, karena saya secara eksplisit mengatakan beberapa kali bahwa saya cukup senang, dan bahwa Electron adalah teknologi yang tepat untuk kebutuhan (spesifik) saya.

Saya hanya mengatakan bahwa saya melihat banyak orang mengeluh di mana-mana tentang ukuran paket dan saya hanya menawarkan solusi (sekali lagi naif) untuk masalah itu, yang tampaknya ideal bagi saya. Tapi saya sangat mungkin salah dan dalam hal apapun itu sama sekali tidak akan mencegah saya menggunakan Electron untuk kebutuhan masa depan saya :)

Bahkan jika opsi runtime tersedia, kemungkinan pengguna tidak akan memilikinya dan harus mengunduh 40+ MB untuk menjalankan proyek Anda.

Ya, tapi saya tahu banyak orang, bahkan di sini di pusat kota Paris, yang hanya memiliki koneksi internet 5Mbps, dan bagi orang-orang itu, menghemat 40MB (yaitu 320Mb) untuk setiap aplikasi berarti menghemat beberapa menit setiap kali aplikasi diperbarui (jangan lupa bahwa 40MB akan untuk setiap pembaruan, bukan hanya pemasangan pertama), mengingat koneksi internet mereka tidak digunakan.

Itu bahkan tidak memperhitungkan penghematan RAM, terutama untuk notebook. Sekali lagi, saya tidak merasa khawatir secara pribadi karena saya memiliki mesin yang relatif bagus dengan RAM 32GB, tetapi saya tidak memikirkan diri saya sendiri di sini, melainkan tentang orang-orang yang mengeluh, dan berharap menemukan solusi untuk mereka.

Last but not least, Anda mungkin memiliki koneksi yang baik, dan saya juga (yang secepat kilat jika Anda mau! :) ), dan kami berdua mungkin memiliki RAM 16 atau 32 atau 64GB, itu sebabnya Anda (sendiri) tidak' tidak keberatan mengunduh 40MB untuk setiap pembaruan, tetapi bagaimana dengan pengguna Anda (mengingat Anda mendistribusikan aplikasi Anda kepada orang-orang)?

Bagaimanapun, saya tidak akan bertengkar tentang ini, saya hanya berusaha membantu, dan seperti yang saya katakan, saya cukup bahagia, dan saya memiliki banyak hal untuk diperhatikan.

Jika beberapa orang berpikir saya dapat membantu mereka memikirkan solusi, saya akan dengan senang hati membantu, tetapi jika tidak, saya akan kembali bekerja :)

Bersulang,

Satu hal yang saya lihat ketika memindahkan lebih banyak dependensi ke devDependencies, semakin banyak waktu yang dibutuhkan untuk membangunnya.

````
membangun proses utama

• proses penyaji bangunan
  ````

Itu menghabiskan lebih banyak waktu untuk "membangun proses penyaji", dan ikon animasi berhenti seperti mogok tetapi tidak. Kemudian itu menunjukkan 203778 md dari laporan penyaji.

Memindahkan devDependencies kembali ke dependensi, waktu build normal lagi tetapi aplikasinya besar.

Jika saya tidak mengalami kesalahan saat membangun, itu berarti semuanya baik-baik saja kan?

@karimhossenbux Ini normal bagi saya. Ada fungsi berjalan di electron-packager yang melewati semua dependensi untuk menentukan apakah mereka harus ada atau tidak. Dengan dependensi gaya datar baru alih-alih bersarang, akan membutuhkan waktu lebih lama untuk menentukan dependensi yang tidak dibutuhkan. Sejauh yang saya tahu tidak ada cara untuk menyiasati waktu pembuatan tambahan.

@baconbrad Terima kasih! Saya menggunakan electron-builder tapi saya rasa cara kerjanya sama.

Apakah ada pembuat paket elektron yang hanya menyertakan sumber Anda dan mengunduh yang lain (hanya diperlukan untuk pengguna sistem operasi saat ini berjalan) ketika pengguna menjalankan aplikasi Anda untuk pertama kalinya?. Ini akan memudahkan distribusi dan akan mengurangi ukuran aplikasi Anda secara signifikan.

Elektron, tolong jangan pergi ke rute "ERE". Ya, saya tahu Anda kembung, tetapi saya suka bagaimana orang dapat mengunduh aplikasi saya dan itu hanya berjalan dengan baik tanpa harus dipusingkan dengan menginstal deps, memperbarui lingkungan runtime, atau omong kosong apa pun yang saya pikir kami singkirkan sekitar tahun 2003 .

Nah, mengunduh bundel masih menjadi pilihan. Tidak ada yang perlu dikeluhkan
tentang disini :)

Le ven. 25 mei 2018 21:03, Luke Pighetti [email protected] a
écrit:

Elektron, tolong jangan pergi ke rute "ERE". Ya, saya tahu Anda kembung,
tapi saya suka bagaimana orang dapat mengunduh aplikasi saya dan itu berjalan dengan baik
tanpa harus dipusingkan dengan menginstal deps, memperbarui runtime
lingkungan, atau omong kosong apa pun yang saya pikir kami singkirkan sekitar
2003.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/electron/electron/issues/2003#issuecomment-392151709 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AApUIBjAeVZ7T4SKo8LyW6RT65XnpiKgks5t2FWfgaJpZM4FGGer
.

Saya hanya menunggu insinyur Microsoft untuk meningkatkan Electron.
https://news.ycombinator.com/item?id=1729973

Saya hanya menunggu insinyur Microsoft untuk meningkatkan Electron.
https://news.ycombinator.com/item?id=1729973

@zcmgyu Microsoft telah mempekerjakan pengembang untuk mengerjakan Electron selama beberapa tahun sekarang sejak mereka mulai menggunakannya untuk VS Code. Dan mereka adalah beberapa kontributor terbesar dan telah sedikit meningkatkannya.

Jika aplikasi Anda lebih dari 100MB,
mungkin exe Anda menyertakan sebagian besar folder node_modules Anda.
Perhatikan bahwa semua yang dideklarasikan dalam package.json dalam dependensi diimpor kembali ke executable akhir.
(Sangat sederhana untuk memverifikasi: cukup untuk mendekompilasi executable)
Jadi ingatlah untuk mendefinisikan hanya lib esensial dalam dependensi (log elektron, pembaru elektron) dan tambahkan semua lib lain di devDependencies.

Aplikasi Anda kemudian akan "hanya" 50MB ...

Aplikasi saya kecil- ini repo. Versi eksperimental terbaru berbobot sekitar 700mb
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

Saya juga bertanya-tanya tentang ini. Berikut adalah ukuran untuk aplikasi elektron saya:

  osx - 117.3 mb

linux32 - 60,3 mb
linux64 - 55,2 mb
menangkan ia32 - 47,8 mb
menangkan x64 - 66,2 mb
Terima kasih!

Luar biasa! Bisakah Anda berbagi tentang cara mengurangi aplikasi elektron menjadi ukuran yang sangat kecil.