+100, Itu akan sangat sangat membantu untuk mengurangi ukuran aplikasi.

Bisakah ekstensi .asar diubah? Kedengarannya sangat aneh dalam bahasa hungaria. Pada dasarnya itu berarti the shit dengan cara yang buruk ( link ).

.apak? dengan segala keseriusan, ada banyak bahasa, jadi hampir semua ekstensi bisa terdengar aneh di beberapa dari mereka.

Instalasi dan pembaruan runtime IMO harus semudah mungkin. Banyak runtime memiliki notifikasi yang sangat mengganggu. Juga, jika Anda akan melakukan ini, beberapa metadata manifes tambahan harus disediakan, karena versi aplikasi yang lebih baru mungkin tidak berfungsi pada runtime lama, jadi Anda perlu membandingkan versi runtime saat ini dengan versi di manifes aplikasi (bahkan mungkin rentang versi seperti di node paket ), dan kemudian jika runtime perlu diperbarui, buat proses ini semudah mungkin. Saya tidak tahu apa yang mudah bagi kebanyakan orang, tetapi bagi saya itu hanyalah jendela dengan bilah kemajuan atau pesan status ("Mengunduh... 57%", "Memperbarui...")
Saya tidak yakin tetapi pembaruan latar belakang juga dapat dipertimbangkan. Ini mungkin beberapa layanan pembaruan atau hanya unduhan runtime saat aplikasi berjalan dan perbarui saat aplikasi ditutup.

+1 untuk ini. Saya sedang mengerjakan aplikasi yang harus saya kirimkan untuk mac dan windows, dan ini akan sangat menyederhanakan pengiriman.

Ini akan luar biasa!

Beberapa pemikiran:

• Seperti yang dikatakan @YuriSolovyov , kita memerlukan cara untuk mendeklarasikan versi atom-runtime yang kompatibel dengan asar tertentu. Sebaiknya, ini juga memungkinkan untuk menentukan versi yang tepat, karena ini mengurangi beban QA saat merilis aplikasi berbasis asar.
  
  
  
  • Untuk mendukung itu, kita perlu mengizinkan beberapa versi dari atom-runtime yang diinstal secara berdampingan, yang berpotensi tidak terlihat oleh pengguna.
  
  
  • Perhatikan bahwa ini agak bertentangan dengan cita-cita membatasi ukuran unduhan. Namun, perusahaan yang memproduksi beberapa produk berbasis asar dapat melakukan standarisasi secara internal sehingga semua aplikasi mereka masih menggunakan versi yang sama.
  
  
• Anda tidak menyebutkan dukungan untuk pembaruan otomatis atom-runtime di Mac, tetapi itu akan _sangat_ berguna.
• Daripada memiliki instalasi sumber-saja di linux, akan lebih baik untuk mendukung menginstal/memperbarui binari, baik melalui paket .deb/.rpm maupun beberapa metode yang tidak memerlukan hak sudo untuk menginstal (yaitu per pengguna). Untuk runtime yang diinstal per pengguna, pembaruan otomatis juga akan sangat berguna.
• Apakah akan ada dukungan untuk menjaga agar file asar yang diinstal tetap mutakhir - atau apakah itu sesuatu yang harus diimplementasikan secara independen di setiap aplikasi?

Terakhir, bagaimana timeline upaya ini? Apa cara terbaik untuk memulai, jika saya ingin mulai menerapkan bagian ini? Saya terbuka untuk berkontribusi.

@ joshuawarner32 Saat ini ini hanya ide kasar, saya berencana untuk mengerjakannya setelah menyelesaikan beberapa masalah utama kulit atom, tetapi bisa berbulan-bulan kemudian.

Saya pikir itu juga layak untuk melihat runtime yang ada dan bagaimana mereka bekerja/diperbarui, seberapa mengganggu mereka dan apa pro dan kontra lainnya.

Saat ini ini hanya ide kasar, saya berencana untuk mengerjakannya setelah menyelesaikan beberapa masalah utama kulit atom, tetapi bisa berbulan-bulan kemudian.

Sudah sekitar 5-6 bulan. Akan sangat bagus untuk menerapkan ini.

Kami telah membangun implementasi internal ini yang sangat cocok dengan kasus penggunaan khusus kami, dan kami mungkin dapat meningkatkannya. Bahayanya adalah itu sebenarnya terlalu spesifik untuk kasus penggunaan kami, dan tidak ada orang lain yang tertarik dengan kerumitan ekstra.

Berikut adalah highlights dari desain kami:

• Deploy file .asar.gz untuk beberapa aplikasi berbeda di server
• Distribusikan satu build atom-shell kepada pengguna, yang tidak memaketkan kode apa pun untuk aplikasi tertentu
• Saat memulai aplikasi, unduh file .asar.gz yang sesuai (jika tidak ada, atau ada yang lebih baru di server). Ekstrak dan jalankan aplikasi yang ada.
• Pembuatan atom-shell kami menerima argumen --app untuk menentukan aplikasi mana yang akan diunduh/dijalankan

Apakah seperti itu yang ada dalam pikiran orang kulit atom? Apakah hal seperti itu berguna bagi orang lain?

Seperti JRE, ini bisa berupa ERE (lingkungan runtime elektron), dengan file .eapp (aplikasi elektron)

-1 untuk .eapp

+1 Saya membutuhkannya!

Di Windows, kami dapat menyediakan installer dan auto updater untuk atom-runtime, dan mendaftarkan jenis file .asar untuk dibuka dengannya.

Instal Steam di Windows dan lihat bagaimana mereka membuat pintasan game, mereka benar-benar menggunakan pengendali protokol, itu relatif pintar

:+1: pada model Steam.

Tidak ada kendala teknis dalam mengimplementasikan ini, semuanya bisa menjadi aplikasi Electron itu sendiri. Tetapi masalahnya adalah tidak mudah untuk mengimplementasikannya juga, dengan mempertimbangkan semua detail, saya pikir itu membutuhkan tim kecil yang bekerja penuh waktu untuk itu, saya tidak yakin apakah itu akan pernah terjadi.

Tetapi masalahnya adalah tidak mudah untuk mengimplementasikannya juga, dengan mempertimbangkan semua detail, saya pikir itu membutuhkan tim kecil yang bekerja penuh waktu untuk itu, saya tidak yakin apakah itu akan pernah terjadi.

Ada banyak pertanyaan di benak saya bahwa, meski tentu saja tidak dapat diatasi, membuat rencana ini Sulit. Misalnya, katakan "Aplikasi 1" memerlukan 0.30.x dan tidak dapat berjalan di 0.31.x, dan "Aplikasi 2" membutuhkan sebaliknya. Siapa yang menang dalam skenario ini?

Sepertinya banyak upaya dan infrastruktur/kesulitan untuk mengoptimalkan sesuatu yang bukan masalah terbesar kami - ruang disk dan bandwidth, dengan mengorbankan kompleksitas pengembang (yaitu sekarang pengembang harus membuat penginstal rantai gila ini untuk menginstal/ verifikasi Electron, lalu instal aplikasinya)

Saya tidak bermaksud membenci sebuah ide! Saya hanya berpikir bahwa dengan waktu yang kami perlukan untuk melakukan ini, kami malah dapat menghabiskannya untuk masalah besar kami - membuatnya sangat mudah bagi pengembang baru untuk membuat dan menerbitkan aplikasi Electron, dari baris kode pertama mereka hingga mengirimkannya ke pengguna

@paulcbetts Tapi hei, manfaatnya sepadan, bukan? Saat memperbarui aplikasi, pengguna harus mengunduh kurang dari satu mb, bukan ~70mb. Yang berarti kita bahkan tidak memerlukan kerangka kerja pembaruan otomatis dan semuanya, kita hanya perlu mengunduh dan mengekstrak arsip mikro-zip dengan beberapa file.

Saya telah menghabiskan tiga bulan terakhir di daerah terpencil di mana kecepatannya kurang dari 128kbps dan percayalah, ukuran peningkatan sangat menyebalkan, bagian terburuknya adalah masih banyak orang yang masih dalam situasi serupa

Yang berarti kita bahkan tidak memerlukan kerangka kerja pembaruan otomatis dan semuanya, kita hanya perlu mengunduh dan mengekstrak arsip micro-zip dengan beberapa file.

Saya tidak berpikir itu benar, karena hampir pasti di beberapa titik Anda ingin pindah ke versi terbaru dari Electron dan kemudian kerplowie, Anda berada di situasi yang sama (atau setidaknya satu yang sama jeleknya). )

Aplikasi dasar sekarang antara 30 dan 50 MB kecuali Anda memiliki banyak sekali video di dalam paket Anda. Saya tidak berpikir itu peregangan bagi kebanyakan orang untuk men-download. Saya percaya rata-rata video youtube antara 30 dan 40 mb...

Saya hanya ingin membuat catatan di sini, di Cina, kecepatan koneksi rata-rata sekitar 20kB/s (Memang koneksi saya lebih lambat dari ~92% kota saya.) Memperbarui Atom/elektron biasanya membutuhkan waktu sehari penuh wget -c sedang. kecuali cermin taobao digunakan.

Untuk kompatibilitas versi, pengembangan elektron bergerak terlalu cepat untuk memiliki versi catch-all, mungkin semacam pembungkus/pembantu dapat digunakan untuk menggunakan/mengunduh versi utama yang diminta saat aplikasi dimulai?

20kb/s? bagaimana kamu bisa bertahan? Saya tidak bisa membayangkan betapa sulitnya hal itu!

@steelbrain bukan niat saya

@RIAEvangelist Memulai dengan cepat dan banyak kesabaran. Kecepatannya menjadi sangat cepat larut malam, jadi biarkan unduhan berjalan atau dijadwalkan saat Anda tidur. :3

Bagaimanapun, saya pikir tidak akan terlalu banyak pekerjaan untuk menulis pembungkus pihak ketiga (dasar), ada yang mau mencoba?

Namun, file .asar tidak dapat dengan mudah mendeklarasikan versi elektronnya. Mungkin diperlukan sistem deskriptor program lain?

Bagaimana dengan operator versi runtime yang (mengunduh jika diperlukan dan) peluncur memerlukan versi runtime untuk aplikasi Anda? Kita dapat menambahkan entri ke package.json untuk itu.

@YuriSolovyov Kecuali bahwa kita tidak bisa mengatakan runtime menangani file .json secara default. Saya kira itu bisa membaca file asar terlebih dahulu dan melihat package.json, tetapi itu akan sedikit memperlambatnya.

@Tribex ya, alur logikanya seperti:

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

Idealnya, mode run-time harus bekerja seperti cara Steam atau Peluncur Aplikasi Chrome . Masalah utamanya adalah bagaimana kami menangani aplikasi saat run-time ditingkatkan ke versi baru.

Aplikasi Electron mengalami peningkatan dari Electron, terutama modul asli node. Modul asli diperlukan untuk membangun kembali untuk setiap pemutakhiran Electron karena masalah C++ ABI (Ada beberapa masalah kerusakan yang dibuat ulang yang dilaporkan oleh pengguna).

Steam tidak menderita sakit karena setiap game di Steam adalah program yang berdiri sendiri, sebenarnya Anda dapat meluncurkan game tanpa Steam Client. Aplikasi Chrome juga tidak diluncurkan, karena aplikasi Chrome ditulis dalam HTML/JS/CSS yang merupakan jenis bahasa yang ditafsirkan, tidak ada celah yang berjalan di versi Chrome yang berbeda.

@hokein bagaimana kalau kita memiliki "klien" ringan dalam bahasa asli, yang mengunduh banyak bahasa, setiap kali menemukan aplikasi yang bergantung pada versi elektron yang dihapus, ia mengunduh salinannya, lalu menjalankan setiap aplikasi dengan elektron spesifiknya.

Ada rilis Electron baru sekitar sekali seminggu, jadi kemungkinan 2 aplikasi memiliki versi Electron yang persis sama sangat tipis.

Untuk mendukung pendekatan waktu proses, kita mungkin perlu mulai memisahkan rilis ke versi LTS (dukungan jangka panjang) dan versi tepi berdarah. LTS akan untuk produksi dan tepi pendarahan akan untuk pengembangan dan pengujian. LTS hanya akan mendapatkan perbaikan bug dan mungkin beberapa perubahan yang tidak menggantikan io.js utama dan versi shell konten, jadi modul asli harus tetap berfungsi.

mengingat apa yang dikatakan @etiktin , kecuali pengguna memiliki banyak aplikasi elektron di sistem mereka, kemungkinan tidak akan ada manfaat dalam waktu pengunduhan karena mereka masih harus mengunduh waktu berjalan paling banyak setiap saat.

Dalam dua minggu saya telah melihat elektron sekarang saya pikir saya telah melihat 4 rilis.

@etiktin Idealnya, jika elektron mengikuti semver, maka aplikasi dapat mendeklarasikan versi ^0.31, dan akan menggunakan rilis 0.31.x terbaru. Itu mungkin bisa sedikit membantu.

Kami memiliki aplikasi dalam produksi dengan mekanisme pembaruan otomatis semver yang melakukan hal berikut:

1. DAPATKAN titik akhir HTTP sederhana di server yang memberikan versi saat ini (0.3.0, 0.3.1 dll.) dan platform (darwin-x64, win32-ia32, win32-x64 dll.) dari aplikasi.
2. Server mengembalikan "304 Not Modified" atau manifes JSON jika ada versi yang lebih baru.
3. Manifes JSON pada dasarnya adalah daftar folder, file, dan symlink bersarang di versi yang lebih baru.
4. Entri folder dalam manifes JSON terlihat seperti ini: [nama, larik entri anak].
5. Entri file dalam manifes JSON terlihat seperti ini: [nama, hash konten, larik hash konten yang dibagi menjadi potongan 64KB, flag integer yang menunjukkan apakah file dapat dieksekusi atau tidak].
6. Entri symlink dalam manifes JSON terlihat seperti ini: [nama, jalur tujuan].
7. Manifes JSON ini dibuat dan di-cache di server untuk setiap versi. Untuk setiap file dalam manifes JSON, server menjalankan algoritme deduplikasi sederhana untuk membagi file menjadi potongan-potongan panjang variabel menggunakan potongan yang bergantung pada konten, dan kemudian memotong potongan menggunakan SHA256. Ini memastikan bahwa sebagian besar potongan hash untuk versi berbeda dari file yang sama tetap sama, bahkan jika konten digeser beberapa byte. Panjang potongan rata-rata kira-kira 64KB untuk deduplikasi optimal + efisiensi kompresi. Jika potongannya lebih besar, mereka tidak akan terduplikasi juga, jika potongannya lebih kecil mereka tidak akan memampatkan juga. Panjang potongan rata-rata juga akan ditingkatkan untuk file yang sangat besar untuk menghindari terlalu banyak potongan potongan dalam metadata.
8. Saat aplikasi menerima manifes JSON baru dari server, aplikasi akan memeriksa ruang disk kosong yang tersedia dan membuat direktori sementara baru dengan ID unik universal. Menggunakan manifes lokal lama sebagai titik awal, kemudian menyalin potongan dari file lokal atau mengunduh potongan yang hilang dari server untuk membuat ulang manifes baru. Setelah membuat versi baru, itu kemudian memverifikasi struktur direktori dan tanda tangan dari semua konten file. Jika ada yang rusak dalam unduhan, itu akan menghapus pembaruan.
9. Jika pembaruan baru berhasil diverifikasi terhadap manifes, maka versi baru aplikasi akan diluncurkan di jalur pembaruan baru.
10. Versi yang lebih lama memperhatikan bahwa versi lain sedang berjalan, dan mati dengan sendirinya.
11. Aplikasi baru menunggu versi lama dimatikan, lalu menyalin dirinya sendiri ke direktori sementara lain, mengganti nama versi lama menjadi direktori arsip, dan mengganti nama direktori sementara ke lokasi versi lama (/Applications/Ronomon.app). Kemudian berjalan sendiri lagi tetapi sekarang dari lokasi versi yang lebih lama (/Applications/Ronomon.app) dan kemudian membersihkan direktori arsip.
12. Jika terjadi kesalahan selama transisi, versi yang lebih lama tetap berada di jalur kanonik hingga dialihkan oleh panggilan ganti nama.

Secara keseluruhan, ini bekerja sangat baik dalam produksi. Deduplikasi dan kompresi berarti bahwa hanya sekitar 33% yang perlu diunduh untuk pembaruan versi utama dan pembaruan kecil hanya membutuhkan 1-2 MB tergantung pada aplikasinya. Pembaruan otomatis menangani Elektron dan kode aplikasi sebagai satu unit atom, dan tidak pernah melanggar tanda tangan kode apa pun dalam prosesnya.

+1 Untuk ide
+1 Untuk mengganti nama asar

Saya turun untuk membuat masalah tentang ini. Ternyata ini sudah ada, jadi saya akan memasukkan + :100: ke ini
Kami benar-benar membutuhkan solusi seperti JRE atau .NET atau Adobe Air, karena mengemas runtime dengan setiap aplikasi membuatnya sangat besar.

Adakah pembaruan tentang runtime yang terpisah dari aplikasi?

Apakah ini ditutup karena solusi telah dikembangkan?

@PierBover masalah ini terbuka.

ini - https://github.com/KeitIG/museeks/issues/48 - ditutup. di repositori orang lain.

Oh terima kasih @championswimmer dan maaf atas kebingungannya.

Jadi apakah ada berita tentang runtime independen? Apakah ini sesuatu yang sedang dikerjakan?

@PierBover itu mungkin tidak akan terjadi dalam waktu dekat karena fragmentasi versi saat ini (sulit untuk menemukan 2 aplikasi elektron yang menggunakan versi yang sama persis). Mungkin setelah v1 dirilis.

@jorangreef apakah Anda menggunakan mekanisme pembaruan diferensial di semua platform? Akan luar biasa jika Anda bisa merilis kode itu sebagai modul mandiri.

@championswimmer Ya, saya telah berhasil membuat skrip build untuk aplikasi saya, jadi saya baik-baik saja mendistribusikan aplikasi saya sekarang. Tapi aku mengawasi ini karena itu akan menarik.

@etiktin Ya, pembaruan otomatis diferensial saat ini berfungsi di semua platform. Jika itu juga termasuk penginstal minimal yang melakukan pengunduhan, maka penginstal dapat dibagikan oleh beberapa aplikasi, dan menggunakan versi Electron yang di-cache jika sudah tersedia. Ini akan berfungsi untuk membuat pemasangan lebih cepat. Saya ingin membuka sumbernya jika orang tertarik, dan akan mencoba merilis kode dalam beberapa bulan ke depan.

Misalnya, katakan "Aplikasi 1" memerlukan 0.30.x dan tidak dapat berjalan di 0.31.x, dan "Aplikasi 2" membutuhkan sebaliknya. Siapa yang menang dalam skenario ini?

Kemudian mereka harus menginstal dua versi dan akan ada dua runtime, sama seperti VS C++ 2008 hidup berdampingan dengan 2005. Saya sangat suka bagaimana runtime VS C++ diinstal, penginstal akan menginstal versi yang diperlukan jika tidak ada, dan yang lain dapat bergantung pada nanti, dan runtime yang berbeda dapat hidup berdampingan. Penegakan persyaratan versi juga tampaknya lebih mudah dilakukan di penginstal.

@louy2 Ada perbedaan antara contoh Visual C++ (3 tahun antara rilis), dan Electron (setidaknya 3 rilis per bulan)

Saya akan menyindir dengan kutipan 'ini adalah sistem yang rusak' di sini, jika mayoritas
aplikasi di ekosistem Electron tidak kompatibel dengan +- 0,0.1 atau
Perbedaan versi 0.1.0

Pada 20 Februari 2016 pukul 18:55, Pierre de la Martinière <
[email protected]> menulis:

@louy2 https://github.com/louy2 Ada perbedaan antara
Contoh Visual C++ (3 tahun antara rilis), dan Electron (3 rilis per
bulan setidaknya)

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/atom/electron/issues/673#issuecomment -186595285.

+1

Saya telah mengemas elektron ke paket .deb menggunakan fpm . Ini bisa menjadi titik awal yang adil di Linux (setidaknya berbasis Debian atau RPM). Anda dapat melihat di sini: iamale/electron-deb ; juga contoh aplikasi yang ada . (Ini akan bekerja dengan asar juga, hanya perlu menambahkan entri MIME ke dalam paket runtime.)

Akan sangat bagus jika kami memiliki sesuatu seperti itu di platform lain juga! Saya mungkin dapat mencoba mengemasnya untuk Windows, tetapi saya tidak menggunakannya secara aktif lagi, dan tidak benar-benar memiliki banyak pengalaman dengannya.

(Terima kasih kepada @louy2 untuk menunjukkan utas ini kepada saya!)

Omong-omong, apa tipe MIME untuk .asar? Apakah application/x-asar bisa?

@iamale Alih-alih fpm , apakah Anda sudah melihat AppImageKit . Manfaat utama yang Anda dapatkan adalah alih-alih membuat banyak pustaka dan semuanya, Anda dapat menargetkan semua distro linux dengan satu yang dapat dieksekusi. Anda juga tidak lagi harus meminta pengguna untuk menginstal dependensi apa pun karena mereka dibundel dengan executable. Ini proyek yang bagus, silakan lihat.

dan tentang pantomim, bagaimana dengan application/x-electron ?

@steelbrain Itu ide yang bagus. Namun, ini tidak akan menyelesaikan masalah awal: runtime Electron harus dikemas dengan setiap aplikasi (karena gambar harus mandiri), itulah yang menjadi topik masalah ini. Meskipun saya pikir itu harus relatif mudah untuk membuat AppImages dari aplikasi Electron, dan saya percaya ini akan bagus ketika manajemen paket tradisional tidak dapat digunakan (distro langka atau pengguna yang tidak memiliki hak). Jadi, terima kasih telah menunjukkannya!

application/x-electron kedengarannya bagus, mungkin akan tetap menggunakannya.

Menambahkan dukungan ashar! Belum ada di repositori, akan dibangun kembali hari ini atau mungkin besok. Untuk saat ini, Anda bisa mendapatkan paket di transfer.sh (tautan akan berlaku selama 2 minggu ke depan)

Anda memerlukan asar.json di dalam .asar, untuk memberi tahu:

• versi yang direkomendasikan
• versi yang kompatibel
  Setelah selesai, Anda memerlukan satu aplikasi yang menggunakan elektron (versi apa pun) untuk memeriksa web untuk (1) pembaruan untuk dirinya sendiri (pemeriksa) dan (2) versi yang ada di komputer Anda, kemudian jika ada versi yang kompatibel, ia akan mem-parsing jalur pembuka ke .asar yang dibuka, jika tidak, unduh versi yang disarankan dan periksa lagi. Aplikasi itu sendiri, dapat ditulis dalam Electron, atau python (karena hanya membutuhkan UI minimal atau tidak sama sekali).

Idenya adalah: Aplikasi yang memeriksa apakah versi elektron yang diperlukan untuk diunduh tidak ada hubungannya dengan versi elektron yang dibutuhkan.

Jika perlu, Anda dapat memperbarui konten default_app, serta aplikasi lainnya, kecuali itu.

Dan di sana, Anda dapat menyimpan versi dengan app.setPath("userData", __dirname + "/ElectronVersions"); kemudian versi tersebut dapat dibiarkan begitu saja, dan yang baru diinstal sesuai kebutuhan.

Alih-alih fpm, apakah Anda sudah melihat AppImageKit .

Ada AppImage of Atom yang tersedia di https://bintray.com/probono/AppImages/Atom/_latestVersion#files - cukup unduh, chmod a+x , dan jalankan pada distribusi Linux x86_64 yang tidak terlalu ketinggalan zaman.

Masalahnya bukan hanya linux, kita perlu cara untuk membuatnya cross-OS, yang berarti kita harus bisa menjalankannya di Linux, Windows dan Mac OSx.

Beberapa jenis peluncur khusus os yang mencari jika runtime tersedia dan mutakhir/kompatibel dengan paket asar

(bertahun-tahun kemudian) Biarkan saya meringkas diskusi:

1. @zcbenz mengusulkan runtime yang mengelola instans Electron lokal sehingga paket .asar hanya didistribusikan dan bundling binari Electron dihindari. Runtime juga mengatur eksekusi paket .asar .
2. @YurySolovyov menyarankan peningkatan file manifes dengan informasi tambahan (misalnya diperlukan versi Elektron) sehingga runtime tahu versi mana yang akan digunakan untuk paket .asar yang mana. Sebuah gambaran dari pendekatan ini diberikan di sini .
3. @joshuawarner32 memperkenalkan ide beberapa versi runtime, pengemasan biner (misalnya sebagai .deb ), dan pembaruan otomatis untuk paket .asar . Selain itu , gagasan tentang server distribusi juga dipertimbangkan.
4. @paulcbetts menyarankan untuk melihat sebagai model Steam dan mengimplementasikan sesuatu yang serupa. Dia menunjukkan komplikasi yang terkait dengan gagasan runtime lokal yang mendukung versi Electron yang berbeda, dll.
5. [orang-orang mendiskusikan kecepatan internet di Cina dan urusan masa kecil mereka]
6. @hokein menunjukkan komplikasi ketika runtime ditingkatkan. Khusus wrt. modul asli yang diperlukan untuk dibangun kembali dengan header Electron.
7. @etiktin ingin memiliki versi LTS dan versi terbaru sehingga aplikasi yang siap produksi menggunakan LTS daripada versi terbaru.
8. @Tribex mengatakan jika kita tetap menggunakan versi semantik , kita tidak perlu memiliki turunan lokal dari versi _all_, tetapi hanya yang tidak kompatibel.
9. @jorangreef memberikan contoh sistem pembaruan otomatis diferensial yang sudah diproduksi untuk aplikasi mereka sendiri.
10. @iamale telah membangun paket fpm Electron untuk mengeksekusi paket .asar .

_disclaimer: Saya mencoba memasukkan hanya poin utama diskusi. Mohon maaf jika saya melewatkan sesuatu!_

Saya membaca diskusi sampai di sini, mencoba merangkum poin-poin utama dan ingin membahas beberapa di antaranya. Ide runtime dengan "integrasi platform yang dalam" melampaui instance lokal sederhana. Produk minimum yang layak harus ditentukan, yang bertindak sebagai runtime seluruh sistem. Saya juga menambahkan fitur yang bagus untuk dimiliki yang mungkin berguna. Bagian terakhir menjelaskan perubahan/fitur apa yang perlu diterapkan.

Alasan:

Apa yang dilakukan oleh sebagian besar pengembang (yaitu bundling binari Elektron) seperti menghubungkan semua perpustakaan bersama secara statis! Ini seperti mengirimkan oven dengan setiap pizza yang kami jual.

MVP:

• Manajer lingkungan : melacak instans Electron yang tersedia secara lokal. Ini dapat digunakan untuk memutuskan paket mana yang kompatibel dengan instance mana (menggunakan package.json yang ditingkatkan [lihat di bawah]). Itu juga harus berhati-hati dalam mengatur variabel lingkungan yang benar untuk menjalankan paket.
• Manajer pembaruan : kemungkinan pembaruan otomatis (+ pemberitahuan) dan pembaruan otomatis diferensial telah dibahas. Akan menyenangkan untuk memilikinya sebagai daemon yang menangani pembaruan instance lokal ke versi terbaru.

Senang memiliki:

• Manajer Paket/Ketergantungan : sama seperti Atom apm , manajer paket diperlukan untuk mengunduh paket .asar (dari GitHub atau URL yang diberikan, dll.) dan menginstalnya secara lokal (sebanding dengan apt-get di Ubuntu atau brew di Mac).

Persyaratan:

• File manifes yang ditingkatkan : package.json juga harus berisi semver (atau rentang semver) untuk menunjukkan versi Electron mana yang diperlukan.
• Prosedur pemasangan/pencopotan yang ditentukan : ATM paket .asar berisi semua yang diperlukan untuk menjalankan aplikasi. Namun, dimungkinkan untuk mengirimkan hanya sumber dan mengunduh modul ketergantungan saat penginstalan. Jika kita terlalu berani, kita dapat memiliki semacam direktori _global_ yang berisi dependensi untuk semua aplikasi ( struktur datar npm 3 mungkin membantu). Namun, ini bisa menjadi sangat rumit, sangat cepat (misalnya saat mencopot pemasangan aplikasi).
• Beberapa runtime lokal : jika versi semantik telah diterapkan hingga sekarang hanya ada dua versi yang tidak kompatibel di luar sana 0.x dan 1.x . Versi minor dan patch harus kompatibel ke belakang, jadi kita hanya memerlukan versi terbaru 0.x dan 1.x pada sistem.

Inspirasi:

• Manajer lingkungan/ketergantungan: Python virtualenv , Ruby rbenv , dan juga lihat ruby-build .
• Manajer paket: pip Python, pip apm .
• Manajer pembaruan: Proses zygote Chromium memiliki pendekatan yang menarik untuk pembaruan _diam, latar belakang_.
• Penerjemah kode (untuk beradaptasi dengan API baru): Python 2to3 .

epm (manajer paket elektron) tampaknya sudah diambil sebagai nama...
Mungkin memanggil runtime elec dan aplikasi .tron ? Mungkin ada beberapa masalah merek dagang dengan TRON tetapi kedengarannya keren;)

Mungkin uepm (manajer paket elektron universal), karena ini dimaksudkan untuk dijalankan di semua OS yang didukung oleh Electron... atau epmc (pusat manajemen paket elektron) dan file .epack (paket elektron). Ekstensi, setidaknya, terdengar lebih baik daripada .tron dan tidak dapat dikacaukan dengan film ("beri Anda benda tron ​​itu, Bung" _berikan filmnya_).

Ada juga sejumlah kata di bidang fisika teoretis yang terkait dengan elektron

• fermion
• lepton
• mengenakan biaya
• coulomb
• pauli

Dan, tidak terkait secara langsung, tetapi lebih sesuai dengan apa yang terjadi dengan manajer paket,

• boson
  ;)
  (Saya percaya foton telah diambil)

@kapouer +kuark? tidak yakin apakah itu diambil

Quark diambil, sisanya saya tidak tahu. Tetapi mengapa kita harus mempertahankan status quo, ketika daftar saran ini menyarankan untuk TIDAK mempertahankan status quo? Tapi karena kita sedang melakukannya, mengapa tidak menamakannya Hauldron? Diambil dari LHC. Collider bukanlah ide yang baik, itu memberi produk bayangan negatif, karena maknanya terkait erat dengan perang...

Particle(s) ? Cukup lama.
Daftar partikel di wiki

Meskipun penamaan itu penting, saya masih berpikir kita perlu menyelidiki semantik runtime/update/packaging/distribution terlebih dahulu.

lepton tampaknya sempurna karena ini adalah keluarga partikel yang dimiliki elektron.

Ide yang sedikit di luar cakupan: manajer runtime yang lebih umum akan lebih mengagumkan (dan tidak terlalu sulit untuk diterapkan). Misalnya, kita dapat menyertakan binari @nwjs juga dan mengelolanya dalam versi-manager-thingy yang sama juga (seperti @asdf-vm, tetapi untuk runtime GUI).

Cepat dan kotor: https://github.com/iamale/lepton. Hanya mendukung versi tetap untuk saat ini (semver adalah hal berikutnya yang harus dilakukan), dan aplikasi dibongkar (yaitu belum ada .asar-s).

Bagus!

+1

Bahkan jika tidak ada .asar, @iamale , selama Anda memiliki cara untuk mengetahui file mana yang harus dibuka, saya pikir itu akan baik-baik saja. Seperti, misalnya, Anda dapat memiliki file.something dengan kode json yang menautkan ke package.json sehingga ia tahu apa yang harus dibuka...

Ini ide yang cukup gila, tetapi bagaimana dengan menggunakan bidang electron di package.json untuk membuatnya
paket npm apa saja (yah, tidak seperti APAPUN, tetapi ada yang siap) yang dapat dieksekusi?
Suka:

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

Ini dapat dicapai dengan menambahkan kemampuan electron untuk menginstal paket npm dan membuatnya dapat dieksekusi dan terlihat untuk sistem host.
Seperti

electron install atom

Agar ini berfungsi, kita perlu membagi perintah electron dan bundel runtime yang sebenarnya.

tetapi bagaimana dengan mengganti nama package.json menjadi package.electron dan memiliki konten seperti ini?

run:{
  "name"    : "zDillinger",
  "version" : "0.0.1-1",
  "main"    : "main.js"
},
electron: {
  "recommended": "1.2",
  "compatible": [
    "1.2.1-1.2.5",
    "1.3,1.3.0.1",
    "1.1"
  ]
}

Dalam contoh ini, akan merekomendasikan menggunakan elektron 1.2, jika tidak ditemukan juga memeriksa apakah ada versi antara 1.2.1 dan 1.2.5, jika tidak memeriksa 1.3.1, maka untuk 1.3.0.1, jika tidak periksa untuk 1.1 dan jika tidak, unduh 1.2.

Mungkin ada sesuatu seperti itu secara otomatis mengunduh versi yang disarankan, dan tidak bisa, lalu memeriksa versi yang kompatibel. Dan ambil masing-masing dan setiap yang kompatibel dan periksa, dan jika tidak ada yang berhasil, tanyakan kepada pengguna apakah mereka ingin tidak menggunakan versi yang tidak kompatibel, dan jika mereka menekan no , itu akan berjalan dengan versi yang tidak kompatibel ditemukan di PC, dan jika tidak ada yang ditemukan, alih-alih meminta untuk menggunakan versi yang tidak kompatibel, tampilkan pop-up kesalahan yang mengatakan bahwa tidak ada instalasi Elektron yang terdeteksi.

@sapioit Memiliki manifes terpisah terdengar seperti ide yang bagus untuk saya. Memiliki ekstensi file khusus akan menyederhanakan banyak hal. (Meskipun .electron tampaknya agak panjang.)

Mungkin menurut lepton @iamale , .lept?

Saya tidak melihat manfaat apa pun dari tidak menggunakan package.json , bidang elektron melakukan bagian isolasi. Babel dan ESlint menggunakan teknik ini dan baik-baik saja.
Ini membuatnya lebih mudah untuk memublikasikan aplikasi langsung ke/melalui npm.

Ya, saya kedua @YurySolovyov - saya pikir meletakkannya di package.json lebih tepat

@YurySolovyov Keuntungan dari file tambahan adalah runtime dapat mendaftarkan penangan untuk ekstensi file tambahan dan berjalan secara otomatis sebagai pembuka default file. Sedangkan untuk melakukan ini dengan package.json akan memerlukan mendaftarkan handler untuk setiap file JSON, yang akan menyusahkan pengguna.

@Tribex titik adil.
Mungkin package.electron bisa menjadi semacam tautan yang memberi tahu runtime "Hey, take a look at package.json, it should contain the info on how to launch it" . Ini adalah ide "gila", jadi ya, saya baik-baik saja dengan mengutak-atiknya.

Saya setuju dengan @tribex , kami membutuhkan file terpisah, atau untuk mengganti nama package.json. untuk sesuatu yang lain.

@wurysolovoyov Anda tidak bisa melakukan itu. Satu-satunya hal yang Anda dapat membuka file adalah memiliki ekstensi yang melekat padanya, dalam hal ini setiap ekstensi akan terbuka dengan perangkat lunak yang sama. Jadi, kecuali jika Anda setuju dengan tidak dapat membuka .json dengan apa pun selain electron (yang hanya akan error, kecuali aplikasi elektron yang tepat dibuka), Anda masih dapat melakukannya, tapi mari kita, orang-orang yang ingin dapat membuka file .json , dapat membukanya dengan program yang kita inginkan untuk membukanya.

Jika tidak, Anda tidak akan dapat mengedit file, tanpa membuka editor terlebih dahulu, atau mengubah apa yang akan dibuka .json setiap menit atau lebih.

Maksud saya @YurySolovyov bukan @wurysolovoyov

Mungkin tidak saya jelaskan secara jelas: tujuan dari package.electron hanya sebagai penanda bahwa direktori ini adalah sebuah aplikasi, sehingga runtime dapat merujuk ke package.json yang berada di folder yang sama , dan meluncurkan aplikasi. Jika Anda membuka package.json secara langsung, itu akan terbuka di apa pun yang terkait dengan .json di OS Anda.

Semacam seperti sistem jalan pintas.

@YurySolovyov Dalam hal ini hanya masalah selera jika kita mendefinisikan informasi itu di package.json atau package.electron. Saya pribadi akan memisahkannya hanya karena tampaknya lebih bersih bagi saya. Mungkin properti engine di package.json sudah cukup.

@Tribex itu juga merupakan persyaratan untuk menerbitkan aplikasi ke npm - memiliki package.json yang valid

@YurySolovyov Benar. Jika kita menggunakan package.electron package.json akan tetap ada. .electron hanya akan digunakan untuk menentukan informasi runtime, atau, dalam kasus saran Anda, hanya menjadi penanda.

Pada dasarnya, package.electron hanya akan ada sebagai _marker_ yang dapat diluncurkan, jadi package.json akan tetap ada dengan datanya sendiri, tetapi itulah mengapa file terpisah akan diperlukan: _double click membuka aplikasi _. Saya masih ingin dapat mengganti nama package.electron menjadi my-app.electron atau my-app.electron .

@sapioit yakin, itulah inti dari memiliki file .electron , Anda dapat memberi nama apa pun yang Anda inginkan, selama itu memiliki ekstensi .electron .

Tampaknya masih tidak terlalu bersih bagi saya untuk meminta runtime handler harus melihat *.electron, lalu di package.json untuk menentukan versi elektron mana yang akan dijalankan, yang kemudian membaca package.json lagi.

@Tribex menurut Anda mengapa package.json akan dibaca dua kali?

• Jika kita memasukkan info runtime ke file .electron , runtime akan meluncurkan aplikasi menggunakan package.json dengan asumsi semuanya benar dan gagal-cepat jika tidak.
• Jika kita memasukkan runtime ke package.json secara langsung atau di bawah bagian electron , itu juga hanya membutuhkan 1 read. Dengan cara ini, saya tidak yakin apa yang harus dimasukkan ke dalam file .electron (ide?), Saya akan baik-baik saja meskipun itu kosong.

@tribex .electron dapat menunjuk ke package.json , untuk berjaga-jaga, untuk beberapa alasan, package.json diganti namanya. Dengan cara ini, Anda dapat memiliki package.json untuk NPM dan package.json yang berbeda (mungkin electron.json ) untuk Electron. Mengapa? Mungkin Anda ingin aplikasi Anda memiliki package.json untuk mengetahui hal-hal apa yang harus diimpor dengan pengelola paket, tetapi setelah diimpor, Anda ingin menjalankannya tanpa perlu memindahkan atau mengganti nama file.

_ app.electron _

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

atau

_ myapp.electron _

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

Atau, jika kita memasukkan semuanya ke dalam package.json , kita dapat memiliki tautan .electron saja ke .json yang ingin kita gunakan untuk membuka aplikasi, jadi:

_ app.electron _

{
  "package": "package.json"
}

atau

_ myapp.electron _

{
  "package": "electron.json"
}

Juga, mungkin Anda ingin memiliki dua peluncur di direktori yang sama, satu untuk klien dan satu untuk server, dengan klien menggunakan file server untuk meluncurkan server lokal hanya dengan satu pemain. Dengan cara ini, Anda tidak perlu menduplikasi semua 99% file (dengan asumsi Anda memiliki game yang menggunakan 500+ MB file) dan 5-6 file berbeda, dan menyimpannya di dua direktori terpisah, tetapi hanya memiliki satu tambahan file untuk dapat meluncurkan server sendiri. Secara harfiah, sama dengan memiliki beberapa executable di direktori yang sama.

package.electron terpisah harus diberi nama package.electron.json atau sesuatu yang memiliki ekstensi .json demi editor dan IDE untuk menentukan sintaks dengan benar.

@StreetStrider Saya lebih suka mengajari IDE bahwa .electron sebenarnya valid .json .
Dan ini juga membawa kami ke poin yang kami diskusikan dengan @sapioit tentang asosiasi .json . Saya tidak berpikir OS populer mendukung asosiasi ekstensi ganda. ( .foo.bar )

Anda dapat menambahkan ekstensi .json saat Anda mengeditnya. atau klik kanan dan buka dengan editor, tetapi sama seperti Adobe Air, yang, secara default, membuka file dengan peluncurnya, memungkinkan pengguna untuk membuka file dengan editor, itu tidak akan menimbulkan masalah.

@sapioit Poin yang adil, saya kira saya setuju dengan Anda tentang menunjuk ke package.json.

Bagi saya runtime dan pemain adalah dua hal yang terpisah. Ini datang lebih sebagai pemain sekarang. Dan sepertinya itu tidak akan digunakan secara luas di luar komunitas yang cenderung teknis yang terbiasa dengan konsep manajer paket.

Masalah yang dihadapi adalah membuat runtime. Jenis seperti JRE dan .Net. Bukan pemain.

@baconface Mungkin Anda bisa menjelaskannya? Tidak jelas apa perbedaan yang Anda buat di sini.

@baconface ya, tetapi JRE dan .Net juga dapat diinstal.
Tanpa JRE, file .jar sama tidak bergunanya dengan paket tanpa runtime electron .

Idealnya alat ini akan didistribusikan dengan atau sebagai metode utama pemasangan elektron, idealnya mengurangi masalah penyebaran.

Untuk ini, Anda hanya memerlukan alat kecil untuk membuat executable yang akan meluncurkan file tertentu, yaitu .electron diperhitungkan. Sederhana seperti itu.

.lept terlihat luar biasa, terima kasih!

Saya pribadi berpikir tidak perlu menemukan konfigurasi baru, pkg.engines terlihat cukup mudah bagi saya di sini (seharusnya memungkinkan untuk beberapa ekspresi semver yang rumit, seperti 1.x || >=2.5.0 || 5.0.0 - 7.2.3 dari npm's docs , jadi tidak perlu untuk { recommended, compatible, etc } -struktur seperti dalam contoh @sapioit , saya percaya). (Saya telah menambahkan bidang lepton , karena scripts.run biasanya dipanggil oleh npm start , dan lepton agak memecah semantiknya dengan menambahkan $VARIABLES miliknya sendiri .)

Atau, jika kita memasukkan semuanya ke dalam package.json, kita dapat memiliki tautan .electron only ke .json yang ingin kita gunakan untuk membuka aplikasi

Sepertinya saya juga bukan ide yang bagus. Jika kita memiliki paket dengan beberapa titik masuk, kita masih dapat memiliki semuanya dalam satu package.json, seperti kita memiliki peta scripts sekarang. Saya sedang memikirkan sesuatu seperti ini:

// package.json
{
  "engines": {
    "node": "4.x",
    "electron": "1.x"
  },
  "lepton": {
    "run": "$ELECTRON .",
    "server": "$NODE ./server.js",
    "server-debug": "$NODE ./server.js --debug"
  }
}

# lepton-run [DIR OR TARBALL] [CONFIGURATION]
$ lepton-run . # the default configuration is `run`
$ lepton-run . server
$ lepton-run . server-debug

Kemudian, jika Anda benar-benar menginginkan ini sebagai file yang dapat dieksekusi, di Linux / macOS Anda dapat menggunakan skrip shell sederhana (3 baris termasuk #!shebang), dan di Windows... yah... _(ツ)_/¯

Pertama, Anda mungkin ingin melihat artikel ini, yang menawarkan alternatif yang lebih baik untuk semver, sambil tetap kompatibel dengan hampir semua hal di luar sana: Release.Breaking.Feature.Fix atau mengapa Versi Semantik harus diganti dengan Versi Eksplisit sebagai secepatnya

Kedua, pertanyaannya adalah bagaimana sebenarnya membedakan mereka. Maksud saya, jika server.js sudah menerima argumen --debug , mengapa repot-repot dengan itu dan tidak mengizinkan orang untuk memiliki konfigurasi file mereka sendiri. Mungkin server memerlukan konfigurasi yang berbeda dari klien, seperti klien yang bekerja pada 2.2-2.4 dan server hanya bekerja pada 1.4-1.9.2.1 ...
Melakukan seperti yang Anda sarankan, kami hanya akan lebih terbatas.

Juga, bagaimana dengan menggunakan lebih banyak variabel, tidak hanya --debug ? Bagaimana saya akan menjalankannya dengan lebih banyak variabel seperti itu? Apakah aman untuk melakukan itu? Lagi pula, jika saya ingin satu file melakukan itu, saya bisa melakukannya bahkan dengan file terpisah, tetapi cara ini mengacaukan kemungkinan hasil menjalankan file .lept dengan parameter.

Jika saya ingin menjalankan server dengan parameter debug, bukankah saya cukup meluncurkan .lept dengan argumen --debug ? Atau saya bisa membuat file lain untuk meluncurkan file itu dengan argumen --debug . Bukankah sesederhana itu?
Saya harap saya masuk akal ...

Pertama, Anda mungkin ingin melihat artikel ini, yang menawarkan alternatif yang lebih baik untuk semver

Saya pikir ini adalah ide bagus! Saya tidak berpikir Electron akan beralih ke skema versi ini. Saya juga percaya bahwa meskipun bagus untuk produk pengguna akhir, kami tidak benar-benar membutuhkannya untuk perpustakaan dan mesin dan runtime dan sebagainya. Idealnya, pengguna seharusnya tidak tahu versi Electron mana yang mereka jalankan (kecuali jika mereka mau).

Mungkin server memerlukan konfigurasi yang berbeda dari klien

Ini bisa menjadi masalah, tetapi saya tidak dapat membayangkan proyek yang membutuhkan lebih dari satu versi runtime.

Jika saya ingin menjalankan server dengan parameter debug, bukankah saya cukup meluncurkan .lept dengan argumen --debug?

Ya kenapa tidak:

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

Package.json konfigurasi ganda ini sangat bagus untuk kasus ketika server a) berbagi banyak basis kode dengan klien, dan b) dimaksudkan untuk dijalankan oleh pengguna akhir. Dalam kasus lain, masuk akal untuk memisahkan semuanya menjadi dua repo/paket, masing-masing dengan package.json sendiri.

Ini bukan untuk Electron, tetapi untuk proyek yang Anda bangun. Electron, kemungkinan, memiliki sistemnya sendiri yang diturunkan dari Semantic Versioning agar sesuai dengan kebutuhan mereka, dan kecil kemungkinan mereka akan mengubahnya, tetapi untuk Lepton dan proyek lain yang tidak sejauh ini _ development hell _, mungkin ide yang baik untuk melewatkan versi semantik sama sekali.

Jika saya ingin menjalankan server dengan parameter debug, bukankah saya cukup meluncurkan .lept dengan argumen --debug?

Ya kenapa tidak:

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

Tidak, maksud saya tidak di konfigurasi, tetapi melalui peluncur. Jadi ini:

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

Tetapi luncurkan .lept dengan argumen --myoption=5 tanpa menyentuh file (selain membukanya). Karena saya cukup yakin Anda dapat "_push_" argumen melalui peluncur, Anda juga dapat menghapus kebutuhan --debug , karena Anda akan meluncurkannya dengan argumen khusus jika Anda mau.

Tapi pada satu hal saya pikir kita bisa setuju: Pengguna memang ingin menggunakan versi stabil yang mereka dapatkan dukungannya. Itu sebabnya saya membuat " Lepaskan " nomor itu sendiri, karena orang tidak mungkin mengingat banyak nomor, tetapi mereka biasanya mengingat yang pertama.

@sapioit jika bidang "Release" untuk pengguna akhir, untuk apa yang lain? Untuk pengguna akhir ini seharusnya tidak menjadi masalah sama sekali, jika versi baru tersedia dan memerlukan waktu proses yang diperbarui (melalui bump in package.json), maka waktu proses juga harus diperbarui.

Berikut adalah masalah:

1. Pengguna ingin tahu versi mana yang mereka tawarkan dukungan .
2. Mereka tidak ingin mengingat banyak _angka yang tidak berguna_, jadi jika mereka memilih untuk mengingat versinya, mereka lebih cenderung mengingat versi 13 daripada versi 1.7 (misalnya).
3. Beberapa orang tidak ingin memperbarui sampai hal-hal tertentu terjadi, seperti betapa sedikit Driver nVidia tidak diperbarui karena sejak kompatibilitas Thunderbolt ditambahkan, kartu grafis mereka dikeluarkan secara acak (tergantung pada pengguna/kasus , baik setelah mem-boot komputer, setelah membuka game, atau beberapa menit setelah memainkan game). Ini adalah contoh alasan yang bagus (tetapi ada banyak alasan lainnya, seperti iklan KMPlayer atau pembaruan otomatis locked on ) yang mencegah pengguna menggunakan versi terbaru suatu produk. Ini membuatnya lebih mudah untuk melihat log perubahan, dengan menghilangkan kerumitan darinya.

Itu hanya beberapa alasan... jika Anda bisa masuk ke rincian lebih lanjut, saya juga bisa masuk ke rincian lebih lanjut dan menjelaskan lebih baik mengapa pilihan itu dibuat.

@sapioit Bukankah rentang semver seperti >= 12.1 cukup fleksibel untuk mendeklarasikan dukungan?
Jika ada versi runtime baru yang tersedia, dan itu memenuhi rentang versi, semua peluncuran aplikasi berikutnya harus menggunakan runtime terbaru yang memungkinkan.

Haruskah mereka? Tetapi bagaimana jika mereka memutuskan untuk tidak melakukannya, karena keterbatasan teknis (seperti iklan KMPlayer dan Driver nVidia)?

@sapioit Maka pastikan Anda menyatakan rentang runtime Anda dengan benar

@sapioit @YurySolovyov Apakah diskusi ini relevan di sini? Manajer runtime harus mengikuti sistem versi apa pun yang digunakan elektron. Saya percaya diskusi tentang sistem versi apa yang _harus_ digunakan elektron termasuk dalam edisi lain.

@Tribex agak. Saya mencoba mengatakan bahwa kita tidak boleh terlalu memperumit hal-hal yang pada dasarnya sudah diselesaikan. Tetapi saya setuju bahwa manajer runtime harus melakukan hal yang paling sederhana dalam hal ini.

@yurysolovyov Jadi mengapa tidak mengizinkan sebanyak mungkin bagian dalam nomor versi yang diinginkan pemain?

@sapioit

Ini bukan untuk Electron, tetapi untuk proyek yang Anda bangun.

Lepton belum memiliki skema versi yang ditetapkan (belum), dan paket (aplikasi) dapat menggunakan skema versi apa pun yang mereka inginkan. Kami perlu menangani ini (misalnya, jika kami ingin mendukung pembaruan aplikasi melalui Lepton itu sendiri).

Runtime, idealnya, harus menggunakan semver, karena itu bukan produk, tetapi sekali lagi, versi 3 angka apa pun sekarang didukung (pengembang harus berhati-hati dengan menentukan rentang). Jika kami perlu mendukung lebih dari 3 angka (seperti dengan proposal Versi Eksplisit Anda), kami perlu memperluas parser (untuk Python, saya sarankan forking k-bx/python-semver atau podhmo/python-semver — yang pertama telah diperbarui baru-baru ini, sedangkan yang pertama mengikuti API node-semver lebih erat dan itulah yang saya gunakan saat ini).

Bisakah saya mengatakan bahwa memiliki manajer paket runtime yang ditulis dengan python untuk proyek nodejs hanyalah ide yang buruk.
Mari kita tidak melakukannya. Apapun namanya, lepton, atau apalah. Mari kita tulis di node, atau gunakan yang lain. Dan jangan spam masalah ini dengan surat yang tidak perlu tentang bagaimana Anda pikir Anda tahu lebih baik daripada skema versi semantik yang dipikirkan dengan baik

@championswimmer Akan menarik untuk membangun runtime manager dengan versi elektron yang dikemas dengannya, dan UI untuk menunjukkan ketika versi lain sedang diunduh.

@championswimmer iamale/lepton adalah semacam implementasi referensi sekali pakai: Saya hanya memasangnya untuk menguji berbagai ide yang beredar di sekitar utas ini, tidak lebih.

@iamale mungkin Anda harus menyatakannya di readme untuk menghindari kebingungan?

@YurySolovyov Selesai!

Untuk implementasi sebenarnya, kami memiliki dua opsi: apakah kami menggunakan node.js, atau bahasa yang dikompilasi seperti C/++ atau Go; dan untuk node, kita harus menggabungkan node.js dengannya (atau mungkin hanya menjalankannya di salah satu instance elektron yang diunduh? Kita harus memastikan bahwa itu berjalan pada _any_ versi elektron waras).

@iamale Tidak juga, kita hanya perlu menjalankan versi default yang diinstal. Setelah itu, pembaruan dapat mengubahnya ke versi yang lebih baru di tempat.

Saya lebih memilih untuk menggunakan satu versi tertentu, karena jika diperlukan, semuanya dapat diperbarui ...

Lepton mungkin bukan nama yang bagus sekarang karena format gambarnya .

Jadi... apa yang kita sebut sekarang? Hadron ?

Kuark? Jika seseorang ingin menggunakan nama "Muon", saya dapat mengganti nama salah satu proyek saya.

Bukankah penamaan sebenarnya adalah bagian yang paling tidak penting di sini?
Apakah kami menyetujui semantik instal/perbarui/runtime?

Mengapa tidak electron saja ...

Op 15 Juli 2016 om 13:22 heeft Joshua Bemenderfer [email protected] het volgende geschreven:

Kuark? Jika seseorang ingin menggunakan nama "Muon", saya dapat mengganti nama salah satu proyek saya.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

@yurisolovyov Saya pikir kami setuju... kurang lebih.
@job-v Itulah yang saya sarankan selama ini. Mari kita pilih satu dan patuhi itu.

@zcbenz apakah Anda mengamati utas ini?
Jika demikian, akan menyenangkan untuk memiliki beberapa visi tentang bagaimana ini harus bekerja untuk mendapatkan beberapa petunjuk di sini.

Hai
ada pembaruan tentang runtime elektron ini?
@zcbenz apa pendapat Anda tentang semua diskusi tentang:

• memilih versi elektron
• menginstal versi yang sesuai
• siapkan untuk bekerja di win, linux, mac
• alat apa yang digunakan untuk membangunnya (python, node, go, c++)?
  @YurySolovyov @sapioit terima kasih atas ide-ide luar biasa Anda
  @iamale adalah solusi Anda bekerja untuk destros berbasis debian 'ubuntu ...'

@alnour-altegani
Ya, ini akan bekerja untuk semua distribusi berbasis dpkg karena kami tidak bergantung pada paket luar. Paket RPM dapat dihasilkan dengan cara yang sama, mengapa tidak?

Saya sedang berpikir untuk memulai repo pusat untuk semua hal Elektron, jadi Anda bisa menjalankan:

sudo sh -c "echo 'deb https://epkg.example.org/ /' > /etc/apt/sources.list.d/epkg.list"
sudo apt-get update
sudo apt-get install min-browser  # or whatever

@iamale Saya pikir menjadikan elektron sebagai paket deb dan menggunakannya sebagai ketergantungan dalam aplikasi yang akan diinstal secara manual atau dari repositori pusat untuk banyak paket deb versi elektron.
dan kemudian gunakan paket ini setelah instalasi untuk menjalankan aplikasi pengguna

Jika ada yang mulai mengerjakan sesuatu untuk ini, mungkin menautkannya di sini ...

@sapioit Saya sudah mulai mengerjakan solusi Linux (APT/RPM). Layanan sederhana tempat Anda mengunggah .asar dan diubah menjadi paket dan ditambahkan ke repositori. Harus dapat diperluas ke Windows dan macOS juga, tetapi tidak ada janji untuk itu untuk saat ini.

@iamale Keren! Beri tahu saya ketika Anda membuatnya berfungsi di windows.

Bagaimana dengan membuat runtime Flatpak untuk Linux? Dengan cara ini, waktu proses dapat dibagi di antara beberapa aplikasi, dan Anda juga mendapatkan kotak pasir.

Dengan Flatpak menghapus ketergantungannya pada systemd itu mungkin akan menjadi universal di Linux untuk pengemasan upstream.

runtime dapat dibagi antara beberapa aplikasi

Saya pikir dengan Flatpak itu tidak mungkin?..

@iamale Flatpak dirancang untuk berbagi waktu proses - pengembang aplikasi memilih waktu proses, menginstal SDK untuk waktu proses tersebut, lalu membangun aplikasi dengan flatpak-builder atau yang serupa. Kemudian ketika pengguna menginstal aplikasi, Flatpak menginstal runtime terkait.

@moosingin3space Terima kasih atas penjelasannya! Itu pasti layak dipertimbangkan saat itu.

Hal lain yang saya suka tentang Flatpak adalah bahwa ia telah dirancang di sekitar kasus penggunaan di mana pengguna menambahkan repo yang dijalankan oleh runtime dev dan app dev (secara transparan) dan ini membuat pembaruan otomatis.

Satu-satunya hal yang saya lihat sebagai masalah terkait dengan keamanan - perlu memodifikasi pustaka sistem untuk menggunakan antarmuka "portal" di Flatpak untuk memungkinkan keluarnya kotak pasir dengan aman.

Tampaknya ada pekerjaan di Flatpak di sini: https://github.com/endlessm/electron-installer-flatpak

Sebagai catatan tambahan, Flatpak didasarkan pada proyek OSTree , yang melakukan pengalamatan konten untuk pohon sistem file. Ini berarti bahwa file dengan checksum yang identik secara otomatis dihapus duplikatnya pada disk, dan pembaruan dilakukan menggunakan delta statis. Ini berarti bahwa Electron tidak hanya dapat menyediakan runtime berbagi yang dapat diperbarui dan dibagikan secara independen di seluruh aplikasi, tetapi juga bahwa aplikasi yang dibangun di atas file yang identik akan secara otomatis membagikannya di disk, dan setelah aplikasi dan/atau runtime diinstal, pembaruan tidak memerlukan unduhan penuh.

Maafkan saya jika ini agak naif, saya bertanya-tanya apakah kemungkinan membangun lingkungan desktop sebagai perkembangan logis alami dari lingkungan runtime telah dipertimbangkan. Idenya adalah bahwa ada aplikasi peluncuran yang memuat elektron saat startup (bukan katakanlah, atom) dengan kemampuan untuk meluncurkan aplikasi elektron lain (mengingat perpustakaan yang berkembang besar) dengan memunculkan instance baru dari penyaji atau bahkan mungkin menggunakannya kembali dan memiliki aplikasi terbuka di tab baru.

Chrome seperti pada OS dalam pemahaman saya tampaknya persis seperti ini (tetapi membatasi dirinya pada aplikasi web). Memiliki aplikasi desktop dengan akses fs penuh melalui nodejs (sebagai lawan dari keterbatasan chromeAPIs) dengan elektron sebagai lingkungan runtime di atas Linux (atau bahkan mengganti atau setidaknya menambah explorer.exe awal di Windows) akan sangat menarik. Saya pikir ini adalah solusi yang lebih bersih daripada ChromeOS yang memuat apa yang secara efektif merupakan runtime dan kemudian mesin browser dan kemudian menghosting aplikasi - di sini seseorang akan memuat aplikasi secara langsung di runtime dan browser itu sendiri hanya akan menjadi aplikasi lain (dan ada begitu banyak proyek browser elektron inovatif di alam liar).

Sekali lagi, saya bertanya-tanya apakah ini telah dipertimbangkan atau apakah sudah ada proyek yang melakukan ini. Jika tidak, mungkin peri dapat memberi tahu manajemen Github untuk memimpin????

PS: Satu hal yang tidak saya sarankan di sini adalah porting OS.js (yang merupakan proyek kecil yang lucu itu sendiri) ke elektron tetapi menciptakan lingkungan untuk aplikasi elektron (Meskipun saya tidak akan menolak penggunaan kembali kode dari OS.js).
PPS: Saya akan membuat masalah terpisah sebagai masalah jika dianggap cukup layak atau jika itu merupakan gangguan terhadap masalah lingkungan runtime.

Saya pikir lingkungan runtime bawaan akan membuat aplikasi Electron jauh lebih baik. Saya pikir mengemasnya seharusnya hanya membuat zip file dan mengganti nama ekstensi menjadi asar , tetapi arsip itu harus memiliki dua folder, satu bernama asar , dengan konten folder runtime default, dan satu disebut enviroment dengan file yang harus menimpa konfigurasi default.

Misalnya, menjalankan aplikasi baru akan menyalin versi Electron yang diperlukan di folder temp dan memindahkan runtime (isi folder asar ) ke lokasi file default, sedangkan folder opsional enviroment (dengan 3 subfolder, windows , linux , macosx ) harus berisi file yang akan ditempelkan ke folder default, menimpa isinya.

Dengan cara ini, kita hanya memerlukan aplikasi atau sesuatu untuk menilai ekstensi .asar ke suatu aplikasi, dan membuat aplikasi itu mengakses folder dengan versi Electron yang diunduh (diarsipkan), salin (ekstrak) ke folder temp , dan gunakan konten .asar untuk mengubah apa yang diperlukan, lalu jalankan instance Electron dari folder temp itu dan tunggu sampai mati untuk memaksa menghapus folder temp. Sebagai permulaan, bahkan hanya mendapatkan konfigurasi default untuk bekerja dengan arsip dengan ekstensi khusus pada semua sistem operasi yang didukung akan menjadi lompatan dan batas lebih dari yang sudah kita miliki. Setelah itu, kita dapat khawatir tentang memiliki folder ketiga, config , tempat menyimpan pengaturan konfigurasi saat ini, dan mungkin folder _config di dalamnya, untuk pengaturan konfigurasi default (jika kita membutuhkannya ).

Dengan aplikasi paket Chrome yang segera dihapus, orang akan mencari alternatif. Runtime akan sangat bagus untuk proyek-proyek kecil yang tidak selalu memiliki build/rilis yang tersedia. Karena aplikasi dibuat dengan teknologi web seperti halnya aplikasi Chrome, akan sangat berguna bagi pengguna untuk menjalankan aplikasi dari sumber. Saya tidak dapat membenarkan porting proyek kecil yang tak terhitung jumlahnya ke Electron jika satu-satunya cara pengguna dapat menjalankannya adalah dengan mengunduh rilis biner besar untuk setiap skrip atau aplikasi individual, dan pengguna tidak dapat memanfaatkan menjalankan komit terbaru tanpa membangunnya atau mengunduh Electron's IDE sendiri.

Halo semua, bahkan jika saya tidak berada di dunia JS-centric, saya baru-baru ini memiliki ide yang sangat mirip dengan _Electron_ (yang kebetulan saya ketahui, tetapi tidak digunakan untuk pengembangan) tetapi dengan audiens yang lebih luas; untuk menjelaskannya dengan cara yang sangat sederhana: _cukup batasi teknologi web ke GUI dan sediakan API._

Jadi lanjutkan dengan perpustakaan / runtime bersama versi semantik (dibangun di atas _Blink_, _Skia_, dll; mungkin di – "modern" – _C++_) dan biarkan pengembang memilih bahasa dengan menggunakan binding…
misalnya Anda ingin _JS_, gunakan _Node.JS_; Anda ingin _C++_, tidak masalah; anda ingin _Python_, dengan standar _CPython_ harus dimungkinkan; ada yang lain ? mungkin _SWIG_ bisa membantu. Dalam (hampir) kasus apa pun, kami menang.

Setelah kami memiliki perpustakaan / runtime bersama (bergantung pada OS), Anda menyelesaikan masalah utama dan dapat menguraikan dengan cara apa pun yang menurut Anda terbaik untuk mengirimkan sisanya (selain merevolusi/memodernisasi pendekatan pemrograman GUI untuk kita semua; a langkah besar ke depan!).

Jadi titik awalnya adalah "perpecahan" (bahkan harus memiliki nama yang berhubungan dengan fisika, mengingat fakta bahwa Anda tampaknya sangat peduli dengannya) dari proyek _Electron_… :)

Kami bahkan tidak bisa melakukan addon ke Electron, tapi saya pikir itu tidak akan banyak sukses, kecuali banyak iklan.

@dezzeus Ada upaya pada baris ini sebelumnya yang gagal. Lihatlah runtime dorong yang dimaksudkan untuk meng-host browser pelanggaran .

Saya membaca utas panjang dan menarik ini dua kali, karena saya ingin melihat lebih banyak momentum ke arah ini. Inilah pernyataan terakhir oleh @zcbenz , saya yakin masih relevan:

Tidak ada kendala teknis dalam mengimplementasikan ini, semuanya bisa menjadi aplikasi Electron itu sendiri. Tapi masalahnya adalah tidak mudah untuk mengimplementasikannya juga, dengan mempertimbangkan semua detail, saya pikir _ini membutuhkan tim kecil yang bekerja penuh waktu_, saya tidak yakin apakah itu akan pernah terjadi.

(Penekanan tambahan) - Bagaimana saya menafsirkan ini, jika solusi akan dibangun, itu akan tergantung pada upaya komunitas dan/atau kebutuhan bisnis GitHub dan organisasi lain yang berkepentingan di dalamnya.

Ikhtisar singkat oleh @yan-foto terlihat seperti rencana pendekatan yang masuk akal, dengan tujuan/persyaratan yang jelas. Ada implementasi/prototipe referensi yang disebut lepton oleh @iamale , mengusulkan "manajer versi runtime universal" yang menargetkan Electron. Sebuah komentar oleh @jorangreef sangat menarik, saat ia menjelaskan "sebuah aplikasi dalam produksi dengan mekanisme pembaruan otomatis semver", dengan pembaruan diferensial, deduplikasi (tidak yakin apakah keduanya sama) dan kompresi. Banyak fitur yang dia gambarkan tampak sempurna untuk diadaptasi/diadopsi.

Ini adalah langkah-langkah eksplorasi dan kemajuan yang pasti, dan ini memberi saya harapan bahwa solusi umum yang layak produksi akan lahir dari proses ini.

Sangat menyenangkan melihat masih ada orang yang percaya pada kemanusiaan.

Satu-satunya hal yang menghalangi untuk menjadi sebuah produk adalah kurangnya peluang bisnis langsung yang dibuka oleh pembuatan produk ini (konsep).

@eliot-akira ya, begitulah adanya. Kode yang saya tulis melakukan deduplikasi berbasis konten per file (potongan berukuran variabel) di dalam file untuk meminimalkan unduhan ketika hanya beberapa byte dalam perubahan file. Itu juga hanya memperbarui file-file yang berubah di antara versi dan pembaruan ke aplikasi secara keseluruhan adalah atomik dalam menghadapi kesalahan apa pun. Entah versi baru akan diluncurkan atau versi lama akan tetap di tempatnya.

Saya ingin membuat kode sumber terbuka, dan ada beberapa hal yang masih perlu saya kodekan untuk keseluruhan ide. Akan sangat bagus jika beberapa aplikasi Electron dapat berbagi satu proses pengawas pembaruan otomatis (dengan cache lokal bersama yang tidak dapat diubah untuk deduplikasi di beberapa aplikasi Electron independen).

Tujuan dari keseluruhan pendekatan ini adalah untuk meminimalkan bandwidth unduhan keseluruhan yang diperlukan untuk menginstal dan memperbarui aplikasi Electron, sambil menjaga agar aplikasi Electron benar-benar terisolasi satu sama lain (beberapa aplikasi akan memiliki binari Electron mereka sendiri). Sebuah non-tujuan akan meminimalkan jejak disk.

Pemasangan aplikasi Electron pertama perlu diunduh secara penuh, tetapi pemasangan aplikasi Electron berikutnya akan mendapat manfaat dari cache lokal bersama yang tidak dapat diubah.

Karena ini menyangkut pembaruan otomatis, saya harus memasukkan masalah versi, dan fakta bahwa beberapa sistem versi tampaknya menggunakan jumlah digit yang berbeda untuk versi. Saya, misalnya, menggunakan Versi Eksplisit .

Kami memiliki dua jenis hal yang perlu diperbarui di sini:

• Elektron itu sendiri, yang menggunakan Versi Elektron dan
• Aplikasi, yang kita tidak perlu terlalu peduli tentang SemVer atau apa pun karena umumnya tidak memiliki API (kecuali mereka mungkin menggunakan semacam sistem addon).

Meskipun jika kita perlu mendukung beberapa sistem versi, mungkin kita bisa memiliki beberapa pengaturan di package.json , seperti "breakingVersionComponents": 1 untuk semver dan 2 untuk Versi Eksplisit atau Versi Elektron?

(Pilihan lain adalah menambahkan pemisah lain dalam versi, seperti 1.3:3.7 yang akan memisahkan bagian yang putus dan tidak putus. Semver kemudian menjadi x:y.z dan Versi Elektron x.y:z . Ini akan hancurkan setiap alat di luar sana, saya percaya.)

@jorangreef Jika setiap aplikasi masih memiliki biner Elektron sendiri, ini tidak akan memperbaiki masalah penggunaan RAM berlebih saat membuka beberapa aplikasi Elektron.

Saya melihat komentar lama oleh @joshuawarner32 , yang saya abaikan. Dia menyebutkan contoh yang sudah berfungsi, bukan solusi tujuan umum, tetapi ringkasannya adalah:

- Deploy .asar.gz files for several different apps on a server
- Distribute a single build of atom-shell to users, which doesn't bundle any code for specific apps
- On app startup, download the appropriate .asar.gz file (if it's not there, or there's a more recent one on the server). Extract it and run the contained app.
- Our atom-shell build accepts a --app argument to specify which app to download/run

Bersama dengan contoh @jorangreef (terima kasih atas penjelasan lebih lanjut - edit: oh, saya tidak menyadari setiap aplikasi memiliki biner Elektron sendiri, yang merupakan model yang berbeda dari yang saya kira), saya melihat bahwa orang-orang sudah membangun mereka memiliki solusi spesifik untuk masalah runtime bersama - yang juga menyediakan fitur semacam peluncur/manajer aplikasi . Akan sangat bagus untuk melihat beberapa konvergensi, untuk memecah beberapa fitur yang disebutkan ke dalam modul tujuan umum.

Saya ingin tahu apakah ada modul khusus non-Elektron yang dapat dimanfaatkan, seperti mekanisme unduhan: server runtime, versi, pembaruan diferensial. Tampaknya agak menakutkan untuk membangun semuanya dari awal, jika orang lain sudah "memecahkan" beberapa area ini. @iamale , terima kasih atas pekerjaan Anda di Lepton , di mata saya ini adalah implementasi konkret ke arah solusi.

Ide lain: cukup publikasikan aplikasi dalam npm, dan buat pembungkus npm khusus yang dapat menginstal dan menjalankannya. Akan sangat mudah untuk digunakan saat itu dan mungkin mudah digunakan (tergantung pada kualitas pembungkusnya) juga. Bagaimana menurut kalian?

Untuk proyek oss, kami dapat menggunakan npm sebagai hosting, untuk proyek sumber tertutup, kami harus dapat mengarahkan pengelola paket ke file .asar untuk mengunduh, dan mungkin beberapa metadata lagi. Pertanyaannya adalah, seperti apa manajer yang seperti ini (dan disebut)

Juga, saya ingin tahu apakah kita benar-benar membutuhkan perintah terpisah untuk menginstal aplikasi, mungkin hanya
electron install atom cukup?

Baru saja melihat ini di Node Weekly:

Electrino adalah alternatif kelas bulu eksperimental untuk Electron yang populer dan kuat. Ini mengimplementasikan sebagian kecil dari API yang tersedia di Electron, tetapi ukuran aplikasi keluaran jauh lebih kecil.

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

https://github.com/pojala/electrino

@YurySolovyov Proyek sumber tertutup seharusnya tidak memiliki masalah dengan dipublikasikan di npm juga — sudah ada beberapa Node.js di luar sana, yaitu melampirkan . (Secara teknis, ini bukan di npm, hanya pemuat, tapi saya tetap tidak bisa melihat bagaimana sideloading .asar akan membantu karena masih bisa dibongkar.)

Saya hanya mencoba berpikir bagaimana kita bisa menggunakan kembali ekosistem yang ada sebanyak mungkin.

Tidak yakin kita ingin...

@jorangreef Jika setiap aplikasi masih memiliki biner Elektron sendiri, ini tidak akan memperbaiki masalah penggunaan RAM berlebih saat membuka beberapa aplikasi Elektron.

@Jop-V Tidak, tidak. Saya tidak ingin mengacaukan segalanya dan berakhir dengan monster. Idenya adalah memiliki penginstal/pembaru otomatis hebat yang memecahkan sebagian besar masalah dalam komentar yang membuka masalah ini: https://github.com/electron/electron/issues/673#issue -44580957

Masalahnya bukan memiliki banyak biner pada disk, tetapi dampak jaringan pada pengguna yang harus mengunduh dan memperbarui banyak salinan biner yang sama secara otomatis.

Memecahkan penggunaan memori pasti layak dilakukan. Saya pikir ada berbagai cara untuk melakukan itu tetapi mereka tidak perlu dibundel dengan penginstal/pembaru otomatis yang tidak menduplikasi.

Jika jejak disk juga merupakan masalah, itu dapat diatasi melalui hardlink pada sistem yang mendukungnya, meskipun itu akan mulai melanggar gagasan isolasi antar aplikasi (misalnya jika satu aplikasi memutuskan untuk menulis ke hardlink yang dibagikan dengan yang lain).

Atau, setidaknya pada macOS dalam jangka menengah, APFS akan menyalin file dengan referensi, dengan deduplikasi transparan di bawah kap, meminimalkan jejak disk. Ini akan lebih baik daripada hardlink karena akan menjaga isolasi tetap utuh (salin saat menulis).

@jorangreef Apa gunanya menggunakan binari Elektron terpisah untuk aplikasi? Isolasi macam apa yang kamu bicarakan? Maaf jika itu pertanyaan bodoh, tapi saya tidak mengerti.

@iamale Beberapa aplikasi mungkin menargetkan versi resmi Electron yang berbeda, atau mungkin mendistribusikan Electron yang dibuat sebelumnya yang dikompilasi dari sumber yang dimodifikasi. Pendekatan ini akan bekerja dengan mereka semua. Bahkan dengan perbedaan besar dalam binari (sebagai lawan dari JS dan perubahan aset), deduplikasi akan menghilangkan 70% atau lebih dari persyaratan unduhan, sehingga aplikasi yang menargetkan binari yang berbeda akan tetap diuntungkan.

Dengan pendekatan ini, pengiriman jenis paket apa pun (kumpulan file dan direktori apa pun yang ditentukan oleh manifes JSON), tidak harus hanya aplikasi Electron, juga memungkinkan. Ini mungkin juga aplikasi Python. Ini tidak sesuai dengan pilihan apa pun yang ingin dibuat pengembang terhadap bagaimana mereka menyusun atau mengemas aplikasi mereka (file vs asar dll).

Ide utamanya adalah ekosistem mendapat manfaat dari delta pemasangan/pembaruan yang sangat kecil karena semakin banyak aplikasi menggunakan penginstal/pembaru otomatis yang sama. Saat ini, setiap aplikasi menjalankan pembaruan otomatis pengawasan mereka sendiri dan itu tidak perlu.

@jorangreef Terima kasih! Saya kira ini seperti repositori APT/RPM klasik, hanya lebih "pintar" (tidak perlu mendeklarasikan dependensi Anda atau apa pun).

Pertanyaannya adalah, seperti apa manajer yang seperti ini (dan disebut)

Bagaimana dengan Minifitron (elektron diperkecil)?

Menurut saya file arsip (yaitu .asar ) harus berisi isi folder tempat biner elektron berada, sehingga kita dapat menambah atau mengganti file yang menyimpang dari standar. Kami akan memiliki setiap versi dalam folder atau arsip dan menyalinnya ke folder sementara baru untuk waktu yang dijalankan.

Dan harus ada opsi untuk menginstal atau mengecilkan aplikasi, penginstalan akan membiarkannya sebagai instance baru dari elektron, sedangkan yang diperkecil akan menggunakan md5 untuk menghapus file yang belum diubah dengan membuka arsip .asar (atau apa yang akan kami gunakan) dan arsipkan kembali dan ganti file asli, sebagai status terbaru dari aplikasi yang kami gunakan.

Sekadar memberikan ide lain: bagaimana jika setiap aplikasi Electron memang berisi salinan runtime mereka sendiri, tetapi setelah diluncurkan, mereka dapat memeriksa apakah ada instance Electron yang sudah berjalan (dan versinya) - apakah itu kompatibel (dalam jangkauan semver , dll.), aplikasi dapat berkomunikasi dengannya dan menggunakan instance yang sama; jika tidak kompatibel, maka aplikasi dapat memulai instance Electron-nya sendiri. Itu tampaknya mengatasi masalah mengurangi jejak memori.

(Kemudian lagi, pada saat aplikasi diluncurkan, saya kira sudah ada beberapa contoh runtime..jadi mungkin tidak logis..)

@eliot-akira Punya ide yang sangat mirip saat membaca utas ini.

(Kemudian lagi, pada saat aplikasi diluncurkan, saya kira sudah ada beberapa contoh runtime..jadi mungkin tidak logis..)

Yah, itu bisa memuat cukup untuk memeriksa ini, dan setelah melihat tidak ada "pasangan elektron" yang tersedia untuk berbagi runtime, muat sisanya.

Ini akan menciptakan banyak masalah keamanan. Aplikasi jahat dapat menawarkan versi runtime yang dimodifikasi kepada orang lain, dan mengakses data mereka. Mungkin itu bisa menggunakan segmen memori bersama, menjadikannya hanya-baca, dan aplikasi "pengguna" (yang menggunakan runtime dari aplikasi yang diluncurkan sebelumnya) dapat memeriksa jumlah runtime, tetapi mengembangkan ini untuk semua OS yang ditargetkan mungkin menjadi mimpi buruk ( Saya bahkan tidak tahu apakah ini ada di Windows; saya berasumsi harus).

Jika hanya demi rasa ingin tahu, apakah ini tidak masuk akal? Apakah itu sebanyak, atau mungkin lebih banyak pekerjaan daripada runtime bersama yang terpisah? Apakah itu menciptakan masalah tambahan lainnya?

DITAMBAHKAN KEMUDIAN: Ini mungkin langkah yang jauh, tetapi ada teknologi untuk menghapus duplikat halaman identik pada RAM; mereka sebagian besar digunakan di lingkungan virtualisasi dan hypervisor. Ini adalah hal pertama yang saya pikirkan dan jalankan untuk memeriksa apakah OS saat ini menggunakan ini, dan kemudian mungkin akan ada cara untuk mengatur elektron sedemikian rupa sehingga fitur ini dapat dimanfaatkan, tetapi ternyata tidak.

@jorangreef Jika pengembang memodifikasi biner Elektron, bukankah mereka seharusnya membuat permintaan tarik?

@Jop-V Mereka bisa, tetapi mereka juga bisa mempertahankan garpu mereka sendiri. Mereka bahkan mungkin tidak memublikasikan sumber jika mereka tidak mau — lisensi MIT tidak mewajibkan mereka.

@jkurei Untuk mengeksplorasi ide lebih lanjut, saya membayangkan beberapa cara yang mungkin berhasil:

1) Pembungkus asli tipis di sekitar Electron atau aplikasi itu sendiri, itu akan menjadi "peluncur". Ia memeriksa instance Electron yang sudah berjalan dan versinya: jika kompatibel, serahkan sisa proses peluncuran ke instance itu dan keluar; jika tidak, lanjutkan meluncurkan instance Electron-nya sendiri.

2) Pustaka JavaScript yang dapat diimpor oleh aplikasi itu sendiri ke dalam proses utama, sebagai peluncur. Itu bisa mengimplementasikan protokol yang mirip dengan di atas: menyiarkan keberadaan instance Electron, dan cara aplikasi lain (menggunakan perpustakaan yang sama) untuk menemukan dan berkomunikasi dengannya - mungkin melalui port jaringan..?

@eliot-akira Saya pikir, omong-omong, sudah ada semacam "protokol" primitif yang Anda bicarakan; itu adalah hal di balik app.makeSingleInstance yang entah bagaimana mendeteksi proses Electron yang sudah berjalan dan apakah itu adalah aplikasi yang sama atau tidak (mungkin dengan mendapatkan jalur penuh yang dapat dieksekusi).

@iamale Saya mengerti, metode ini menggunakan kelas ProcessSingleton asli Chromium, untuk mendaftarkan direktori aplikasi saat ini (sebagai pengenal unik?). Ya, saya membayangkan sesuatu seperti ini, untuk diinisialisasi sebelum app.on('ready') . Jadi, alih-alih hanya memeriksa instance aplikasi tertentu yang ada, ia dapat memeriksa instance Electron apa pun - lalu "serahkan proses peluncuran" jika kompatibel.

Untuk sudut lain, saya menemukan modul bernama node-ipc yang dapat berkomunikasi antara proses Node.js yang terpisah. Mungkin itu bisa digunakan untuk mengelola proses peluncuran murni pada lapisan JS.

Berikut adalah contoh dasar berbagi instance Electron tunggal di antara beberapa aplikasi, menggunakan node-ipc untuk komunikasi antar-proses: https://github.com/eliot-akira/singletron-example.

Hub IPC adalah modulnya sendiri , pembungkus tipis di sekitar node-ipc . Inisialisasinya sedang dalam proses utama, main.js di bagian bawah .

Saat dimulai, aplikasi pertama-tama akan mencoba terhubung dengan instance Electron yang ada. Jika tidak ada, itu akan memulai "server" yang mendengarkan permintaan antar-proses. Setiap instance berikutnya dari aplikasi akan terhubung dengan instance pertama, menerima "config" (versi Chrome, Node, Electron), dan dapat bertukar pesan, misalnya, untuk meminta jendela baru untuk dirinya sendiri.

Ini adalah implementasi yang naif untuk memulai, tetapi yang saya sukai dari pendekatan ini adalah bahwa terserah aplikasi untuk menangani bagaimana server/klien harus bernegosiasi: memeriksa kompatibilitas, apakah akan membuka jendela baru, melewati konfigurasi lain, dll.

@eliot-akira Saya pikir menentukan ID server default adalah ide _sangat-sangat-buruk_ pada saat ini: jika ada yang mulai menggunakan ini untuk tujuan mereka sendiri, mereka kemungkinan hanya akan memodifikasi kode contoh Anda untuk kebutuhan mereka sendiri dan melanggar protokol ( sehingga merusak aplikasi lain yang mengandalkan ini).

Selain itu, terlihat bagus dan bersih, terima kasih!

Re: masalah keamanan: Aplikasi Electron sudah berjalan dengan hak istimewa pengguna, dan jika kita menempatkannya di satu pohon proses, mereka memang akan memiliki (atau dapat memperoleh) akses ke instance Electron lainnya. Namun, saya pikir jika kita akan menguranginya, semua orang yang dapat menyediakan instance Electron yang ditambal tentu saja tidak akan membantu.

@iamale Terima kasih atas umpan baliknya. Saya membuka opsi untuk mengatur ID server, jika beberapa aplikasi ingin menerapkan protokol mereka sendiri, daripada yang umum untuk semua aplikasi Electron. Faktanya, belum ada protokol umum seperti itu - jadi, pada titik ini tidak praktis untuk tujuan itu, untuk aplikasi yang tidak dikenal untuk terhubung dan menyerahkan proses peluncuran. Itu dimaksudkan sebagai bukti konsep, jadi saya akan memperbarui dokumen untuk menyebutkannya. Saya akan terus mengeksplorasi bagaimana membuatnya lebih praktis.

Saya pikir akan sangat membantu bagi orang yang baru datang untuk memiliki semacam ringkasan lagi, mirip dengan yang dilakukan seseorang setengah tahun yang lalu.

Juga, apa yang dilakukan pengguna akhir?

Jika saya adalah pengguna akhir (dan sebagian saya daric), saya ingin satu paket .exe/.app/.deb yang berfungsi seperti penginstal portableapps.net. File exe itu harus kecil dan mengunduh versi terbaru dari perangkat lunak secara otomatis bersama dengan Runtime jika tidak diinstal. Dalam proses penyiapan sederhana, saya harus dapat mengatur "lokasi runtime" (menggunakan kotak centang opsi lanjutan) secara manual bersama dengan kotak centang untuk membuat tautan sistem (Desktop, menu mulai, dll.).

Ketika saya mengunduh perangkat lunak berikutnya, runtime sebelumnya (seperti apa pun itu, idc) harus digunakan kembali jika memungkinkan.

Sebagai pengembang, saya ingin dapat membuat paket yang dapat diunduh dengan (paling baik) satu klik. Satu klik ini harus mengunggah kode saya ke beberapa repositori (mirip dengan play/web/app store) dan membuat paket .exe/.app/.deb untuk saya yang dapat saya bagikan dengan dunia.

Saya belum terlalu terlibat dengan Electron, karena saya baru saja membuat penginstal mod kecil menggunakan Electron dan Electron-Edge untuk C#.

Saya mungkin naif, tetapi afaik, satu-satunya alasan "nyata", mengapa hal-hal tidak kompatibel dengan versi +-0.1 adalah bahwa file .node harus dibangun kembali untuk setiap versi Electron. Tidak bisakah file .node ini dibuat selama penyiapan menggunakan semacam solusi cloud?

Juga, apakah itu benar-benar masalah besar untuk membuat satu LTS Elektron besar setiap setengah tahun atau lebih? Saya ragu devs benar-benar menggunakan semua fitur terbaru dari setiap rilis Electron baru, jadi jika kami (semacam) memaksa mereka untuk tetap menggunakan satu versi lebih lama, itu akan membuat segalanya jauh lebih mudah.

Imo, satu-satunya masalah adalah tidak memiliki versi LTS dari Electron yang siap untuk diandalkan semua orang.

Dengan versi itu, membangun pembaruan otomatis, menghapus duplikat, manajemen versi, dan semua hal lainnya harus mudah.

Solusi penginstal yang saya usulkan juga memiliki manfaat tambahan, yaitu pengguna tidak benar-benar melihat folder perangkat lunak, jadi kita tidak perlu mengemasnya sebagai .whatever dan menyuruhnya untuk memindahkannya ke tempat yang aman. Selain itu, beberapa "subexecutable" dapat ditambahkan selama instalasi (misalnya untuk game multipemain, beberapa "profil", dll.). Eksekusi ini seharusnya hanya disebut somelaunchername.electron, tetapi dalam format Json dengan informasi tentang cara meluncurkan perangkat lunak (seperti apa index.html untuk memuat dan hal-hal seperti itu). node_modules harus dibagi antara executable (kecuali dev PERLU menggunakan versi modul yang berbeda untuk setiap executable). Ini dapat dicapai dengan memiliki tiga folder node_modules. Satu untuk setiap executable dan satu untuk keduanya. Di package.json hanya akan ada informasi umum. Setiap file .electron harus (imo) dapat menimpa nilai dalam package.json.

File .electron ini kemudian dapat ditambahkan ke menu mulai dan lokasi lain menggunakan "runtime --appname" atau protokol khusus seperti Steam. Tidak yakin mana yang lebih baik, tetapi yang uap telah membuat saya kesal beberapa kali di masa lalu.

Sekarang jika dev benar-benar ingin mengirimkan runtime yang dimodifikasi, dia masih dapat mengemasnya seperti yang dilakukan saat ini.

Untuk menyimpulkan:
Menurut pendapat saya, langkah selanjutnya adalah membuat versi lts yang stabil dan melibatkan pengembang dengan menyediakan solusi pengemasan yang mudah. Proses instalasi dapat ditingkatkan nanti, saat ini cukup mengunduh runtime dan peluncur untuk file .elektron ini.

apa yang kalian pikirkan?

@CiriousJoker pembuat elektron dapat membuat aplikasi portabel dan penginstal web. Sejauh yang saya lihat, di windows shared DLL adalah solusinya. DLL bersama juga mendukung penghitungan referensi, untuk secara otomatis menghapus runtime elektron yang tidak digunakan. Saat ini, runtime elektron di windows dalam satu exe besar (kecuali node.dll). Jika dapat dipecah menjadi dll, solusi di sisi pembangun elektron cukup mudah diterapkan. Ini juga akan menghemat memori, tidak hanya ruang disk.

@zcbenz @paulcbetts Sudahkah Anda mempertimbangkan untuk menggunakan dll bersama? Apakah mungkin untuk mengurangi ukuran exe dan memindahkan semua kode elektron ke dll (jadi, simpan hanya kode minimal di exe)? Itu keren karena elektron 1.7.5 bersama C runtime dihapus dari node.dll dan exe. Sekarang, 30 MB kode sudah ada di file DLL (tapi exe masih besar — ​​80 MB), jadi, saya bisa mulai bereksperimen dengannya.

@develar imo, masalah sebenarnya bukanlah bagaimana kita dapat berbagi dll, melainkan bagaimana kita bisa mendapatkan elektron versi lts

Apakah Chromium bahkan melakukan perbaikan keamanan untuk versi yang lebih lama? Saya memiliki perasaan yang kuat bahwa kebijakan mereka adalah "upgrade ke versi terbaru agar aman". Tanpa pembaruan keamanan dari Chromium, LTS Elektron tampaknya masih jauh.

@sedwards2009 Tapi apakah ada begitu banyak ancaman? Tentu, saya mungkin naif di sini, tetapi kami tidak melindungi pengguna dari internet terbuka, tetapi dari (kebanyakan) aplikasi lokal. Menjalankan file .exe apa pun adalah 10.000 kali lebih berbahaya dan menulis virus .exe juga 10.000 kali lebih mudah bahkan ketika penginstal untuk aplikasi elektron saya yang sah disebut virus oleh AVG.

Jadi bagi saya, "memperbarui" keamanan itu setiap 6 bulan atau lebih sudah cukup. Juga, jauh lebih tidak aman untuk membiarkan setiap pengembang menggunakan versi chromium mereka sendiri, mereka dapat melakukan jauh lebih jahat dengan itu yang tidak dapat kami cegah (dengan runtime bersama atau lainnya)

Ya, keamanan berakhir di mana aplikasi mendapat akses mentah ke fs dan jaringan.
Anda mempercayai vendor aplikasi atau menjauh. <- itu untuk aplikasi sumber tertutup.
Untuk OSS, lebih baik, kebanyakan dari mereka setidaknya tidak memiliki niat buruk, tetapi mungkin mengandung bug.

Oke, jadi bagaimana cara mudah untuk mendapatkan versi lts? Tidak bisakah kita memilih versi saat ini dan mendeklarasikannya sebagai versi lts?

Masalah yang lebih besar mungkin akan muncul nanti, ketika kami mencoba meyakinkan pengembang untuk membuat aplikasi mereka untuk versi khusus ini, tetapi itu adalah langkah terakhir. Untuk membangun runtime bersama, kita hanya perlu memilih runtime terlebih dahulu

Saya akan mengatakan ini harus menjadi keputusan pengembang - untuk mencari tahu aplikasi versi runtime mana yang harus bekerja.
Jenis seperti bidang mesin npm .
Pekerjaan runtime di sini adalah untuk mengambil dll yang diperlukan atau apa pun dan mengizinkan aplikasi untuk berjalan.

Tetapi jika kita mengizinkan mereka untuk memilih salah satu dari lusinan runtime yang hampir sama yang tidak kompatibel, kita akan benar-benar kehilangan intinya, bukan? Kami mencoba untuk menghindari beberapa runtime, tidak hanya menghapus duplikasinya. Seperti yang disebutkan seseorang di suatu tempat di awal, menduplikasi runtime tidak masuk akal ketika ada kemungkinan 1 dari 20 bahwa runtime yang sama akan digunakan lagi pada sistem yang sama.

Atau maksud Anda bahwa kami memiliki sebagian besar runtime yang dibagikan dan hanya mengganti bagian yang berbeda sesuai kebutuhan? Itu masuk akal, tapi saya membayangkan itu sulit untuk diterapkan

Saya tidak melihat bagaimana runtime dapat dibagikan, konsumen ukuran utama adalah Chromium dan Node, yang terintegrasi erat dan saya ragu mereka dapat dibuat untuk bekerja dengan lebih dari 1 versi satu sama lain.

Saya pikir node memiliki sesuatu seperti itu:

• beberapa pengembang menginginkan v8 terbaru, dan tidak masalah untuk mentolerir kerusakan
• perusahaan besar menginginkan stabilitas dan dukungan jangka panjang.

Saya tidak yakin tim elektron memiliki sumber daya yang cukup untuk mendukung keduanya, tetapi saya mungkin salah.
Bagaimanapun, ini tidak bertentangan dengan rentang versi, hanya perlu menunjukkan versi mana yang "LTS"

Nah jika setiap aplikasi elektron menggunakan runtime yang sama dan hanya dikirimkan dengan paket .asar yang dibuat khusus untuk runtime itu, semuanya akan berhasil, bukan?

Ya, tetapi Anda ingin Chrome dan Node yang lebih baru sesekali, bukan?

Ya, tapi saya bisa hidup dengan memiliki node/chrome yang sama selama 6 bulan np. Node memiliki versi LTS dan chrome tidak banyak berubah dari apa yang saya perhatikan. Imo, manfaat menghemat 100mb pada setiap pemasangan aplikasi menebus sedikit peningkatan kecepatan sesekali setelah versi baru Chromium / Electron keluar. Juga, setelah kami mendapatkan pengembang, seharusnya tidak terlalu sulit untuk mengurangi waktu antara versi baru dari runtime. Kami kemudian dapat mendukung versi terbaru dari runtime dan satu atau mungkin dua yang lebih lama.

Membangun kembali file .node setiap 6 bulan seharusnya tidak terlalu sulit juga saya kira

Pembangun elektron akan mendukung opsi baru untuk semua target nsis — useSharedElectronRuntime. Untuk saat ini, semua dll yang ada akan, saya pikir mungkin untuk mengurangi ukuran exe dan memindahkan kode ke dll, tetapi itu bisa dilakukan nanti, menghemat 30Mb sudah merupakan tujuan yang baik.

1. Buat perakitan yang ditandatangani untuk semua elektron dll dan publikasikan ke rilis GitHub (bintray bukan pilihan, karena tidak dapat diandalkan).
2. Pemasang Nsis akan mengunduh dan memasang rakitan jika belum terpasang. Keamanan — perakitan ditandatangani. Pembangun elektron juga mendukung instalasi per mesin. Dan Windows memberikan tingkat keamanan tambahan jika perakitan diinstal per mesin, jadi, jika perlu, Anda dapat mengaktifkannya. Opsi tambahan akan ditambahkan untuk memasang rakitan per mesin dalam hal apa pun. Belum jelas — apakah secara default benar atau salah. Saya pikir salah, untuk memastikan bahwa secara default aplikasi elektron dapat diinstal tanpa admin.
3. tidak perlu khawatir tentang runtime elektron yang tidak digunakan — dll yang dibagikan mendukung penghitungan referensi. Saat mencopot pemasangan aplikasi, rakitan akan dihapus dan Windows akan menghapusnya jika tidak ada lagi aplikasi lain yang menggunakannya.

@CiriousJoker Re: keamanan. Saya tidak memikirkan masalah keamanan jika aplikasi itu sendiri berbahaya. Saya sedang memikirkan aplikasi elektron yang menyedot dan menggunakan konten yang tidak tepercaya. yaitu setiap kali aplikasi elektron menampilkan halaman web dari web terbuka dalam webview atau yang serupa.

Banyak aplikasi tidak membuka diri ke web terbuka, dan mereka akan berjalan dengan baik pada elektron yang lebih tua. Tetapi ekstrem lainnya adalah sesuatu seperti Brave yang sebagai browser web tidak melakukan apa pun selain mengekspos dirinya sendiri. :-)

@sedwards2009 kamu, tetapi jika kita mulai merawat semua orang dan ibu mereka, kita tidak akan membuat kemajuan apa pun. Akan selalu ada alasan untuk tidak melakukan sesuatu. Tidak mendapatkan 100% devs di papan hanyalah pengorbanan yang harus kita lakukan. Jika mereka benar-benar membutuhkan/menginginkan keamanan, mereka dapat memilikinya secara manual.

Adapun untuk memilih LTS, pilihan yang paling masuk akal adalah mengikat diri kita sendiri ke Nodejs LTS yaitu versi elektron mana yang sesuai dengan node LTS secara efektif adalah LTS elektron. Hal ini dapat membawa beberapa harmoni dan kesepakatan sehingga kita dapat bergerak maju secara kolektif dan memiliki kepastian daripada membiarkannya sebagai pilihan bebas (yang meniadakan komunitas ini) atau berdebat (yang tidak membawa kita ke mana-mana).

@CxRes Tapi versi Electron apa yang kami dukung? Dalam proyek saya, masalah utamanya adalah membangun kembali file .node terhadap versi khusus Electron (bukan Node).

Kita bisa saja mengatur versi Electron terbaru sebagai lts atau menggunakan yang paling banyak digunakan.

Apakah saya melewatkan sesuatu di sini? Imo, masalahnya adalah Elektron, bukan Node

Oke, saya coba jelaskan lagi dengan contoh:

• Node LTS saat ini di 6.11.1
• Oleh karena itu kami ingin menggunakan versi elektron tertinggi yang secara resmi dibangun dengan versi node tertinggi yang memenuhi kondisi <=6.11.1 >=6.0.0
• Versi elektron tertinggi yang dibangun menggunakan Node 6 adalah elektron 1.4.15 yang dibangun dengan Node 6.5.0
• Jadi elektron 1.4.15 adalah tempat kita bercabang untuk elektron LTS dan kita membangunnya kembali dengan 6.11.1 (dan seterusnya sampai ada rilis Node v6 baru)

Ketika Node LTS pindah ke v8 (LTS hanya bilangan genap), kita akan bersama-sama bermigrasi ke elektron yang belum dirilis yang akan dibangun menggunakan Node v8 atau tetap pada fork LTS saat ini sampai versi elektron tersebut dilepaskan.

Bagaimana dengan para pengembang yang menginginkan yang terbaru dan terbaik?

@CxRes @CiriousJoker Mari kita menghindari topik di sini. Tidak ada alasan teknis yang mencegah penggunaan versi Electron yang berbeda. Fragmentasi akan tetap ada (pengembang merilis aplikasi satu tahun yang lalu dan lupa, aplikasi lain dari pengembang lain dirilis baru-baru ini dan menggunakan versi lain).

@YurySolovyov Seluruh ide LTS adalah bahwa ini bukan yang terbaru dan terhebat - stabil. Dan jika kita tidak setuju untuk fokus pada satu solusi - kita pasti akan menderita sub-optimal Pareto karena tidak memiliki runtime karena tidak ada grup yang memiliki waktu dan kemampuan untuk membangun kembali setiap versi dan menyaringnya untuk bug.

Lihat juga komentar @CiriousJoker di atas:

kamu, tetapi jika kita mulai merawat semua orang dan ibu mereka, kita tidak akan membuat kemajuan apa pun.

@develar Oke. Tetapi seperti yang Anda tunjukkan ini bukan masalah teknis, ini politis (mendapatkan kesepakatan tentang bangunan yang bekerja untuk kebanyakan orang secara konsisten sehingga bebannya dibagi).

Jadi apa yang kita lakukan sekarang? Apakah kita memilih versi lts dan memulai atau mencoba menemukan solusi untuk membuatnya berfungsi untuk semua orang dengan mencoba membangun runtime yang cocok untuk semua dengan dll modular (seperti yang disarankan @develar jika saya mengerti dengan benar)

@CiriousJoker Perakitan berdampingan untuk versi elektron tertentu. misalnya ElectronUserland.ElectronRuntimeAssembly.1.6.11.0 .

@develar Saya tidak dapat menemukan hal electronruntineassembly di Google, dapatkah Anda memberikan tautan atau semacamnya?

Imo, untuk mempercepat, kita hanya harus memilih versi Elektron acak sebagai versi lts dan memulai. Kami dapat mengubah versinya kapan saja nanti.
@develar Saya masih tidak tahu apa yang Anda maksud dengan perakitan berdampingan itu, tetapi harus bekerja lintas platform dan saya membayangkan, kami dapat mengimplementasikannya nanti juga.

Kami (atau sebenarnya kalian) telah membicarakan hal ini selama bertahun-tahun, tetapi jika tidak ada yang memulai, tidak ada yang akan berubah dan kami akan duduk di sini selama 3 tahun lagi mendiskusikan ide dan menemukan cara untuk tidak memulai.

Saya berharap pengembang elektron dapat memecahkan pemisahan lingkungan yang berjalan dan aplikasi sesegera mungkin, yang akan sangat mempromosikan aplikasi elektron, dan saya akan melihat masa depan yang cerah.

Mereka tidak menyelesaikannya selama bertahun-tahun bagi saya, jadi saya agak pesimis tentang itu. Tentu, itu akan luar biasa, tetapi apakah mereka bahkan secara aktif mengerjakannya?

@CiriousJoker Seperti yang dinyatakan di atas, saya sedang mengerjakan dukungan runtime elektron bersama untuk windows di pembuat elektron. Saya telah mengajukan https://github.com/electron-userland/electron-builder/issues/1942 untuk melacak kemajuan. Saya berharap ini akan siap digunakan dalam 1 bulan.

@develar Sayang sekali, pasti diabaikan.. Dalam hal ini, semoga berhasil, akan luar biasa jika Anda bisa membuatnya!

Jika ada yang tertarik dengan deduplikasi subfile content-defined-chunking yang dirujuk sebelumnya di utas di https://github.com/electron/electron/issues/673#issuecomment -157980607, saya telah membuka sumbernya: https:// github.com/ronomon/deduplication

Utas panjang ini telah tidak aktif selama beberapa bulan terakhir, tetapi saya pikir masalah yang ditanganinya masih layak untuk diselidiki. Selama akhir pekan saya membuat utilitas satu halaman kecil dan minimal untuk mengganti nama file secara massal. Dikemas dengan pembuat elektron, file .app Mac terakhir berukuran 121mb ...

Saya memikirkan masalah ini akhir-akhir ini. Kemudian saya melihat smartphone saya: aplikasi Facebook berukuran 600MB. Chrome berukuran 325MB, Mesenger berukuran 300MB... Jadi aplikasi 120MB di desktop, saya tidak terlalu peduli...

Ukuran tidak menjadi masalah hari ini. RAM dan konsumsi daya adalah.

_edit: jika Anda tidak setuju, jangan ragu untuk membagikan alasannya_

Untuk platform Windows, upaya @develar dengan pembuat elektron (electron-userland/electron-builder#1942) tampaknya hampir mencapai runtime bersama.

Perhatikan juga webcatalog aplikasi, yang mengemas aplikasi web sebagai aplikasi Electron mandiri, memecahkan masalah penggunaan runtime bersama, untuk mengurangi ukuran aplikasi secara besar-besaran: webcatalog/webcatalog/issues/171. Itu dilakukan di packager mereka, dengan menghubungkan sumber daya bersama di antara aplikasi .

Aplikasi Web Progresif (PWA) adalah solusi parsial untuk masalah ini. Di Android Anda dapat menambahkan PWA ke layar beranda dan itu akan bertindak seperti apk asli. Tim Chrome sekarang bekerja untuk mengaktifkan PWA untuk dipasang di desktop (http://www.androidpolice.com/2017/12/05/google-wants-progressive-web-apps-replace-chrome-apps/), Microsoft juga menunjukkan minat untuk mendukung PWA (https://www.windowscentral.com/faq-progressive-web-apps-windows-10) dan saya harap Firefox dan Safari akan segera menyusul. API yang hilang (misalnya akses sistem file asli) akan ditambahkan jika pengembang menunjukkan minat.
Sebagian besar aplikasi Electron berbasis web dapat dengan mudah dikonversi ke PWA, tetapi saya tidak yakin tentang yang seperti Atom, VSCode - kode asli mungkin perlu ditulis ulang di WebAssembly.

@develar memiliki kemajuan tentang ide ini?

Saya akan menggunakan saat dirilis!

Setelah baru-baru ini menemukan ini, saya hanya ingin menyampaikan pendapat saya. Saya belum membaca seluruh masalah, jadi saya mungkin mengulangi beberapa hal tanpa sadar.

Saya pikir hal seperti ini sangat penting, karena meskipun ukuran program Electron mungkin tidak tampak seperti masalah besar sekarang, Anda benar-benar mulai melihatnya ketika mendistribusikan program yang sangat sederhana dan kecil - katakanlah, kalkulator khusus. Dalam hal ini, sesuatu seperti 5-10MB akan masuk akal. 60MB atau lebih hanya akan konyol. Untuk program yang lebih besar, ukuran Electron itu sendiri menjadi lebih diabaikan, tetapi masih bisa mengganggu.

Sekarang, mode runtime seperti itu, bagaimanapun, memerlukan beberapa jenis sistem rilis LTS dengan mempertimbangkan tingkat rilis saat ini. Pengembang kemudian dapat didorong untuk bergantung pada rilis LTS, dan daftar versi yang paling umum digunakan bahkan dapat ditampilkan di direktori aplikasi, mendorong mereka untuk menggunakan yang paling umum kecuali jika tidak memiliki fitur yang diperlukan.

Mode runtime itu sendiri harus, IMO, memiliki sistem bawaan untuk menginstal versi lain dari perpustakaan Electron juga, sehingga jika pengguna meminta untuk menginstal aplikasi yang memerlukan versi yang berbeda, program runtime kemudian dapat mengunduhnya secara otomatis sebagai sederhana langkah dalam proses instalasi.

Saya pikir perlu dicatat juga bahwa penggunaan RAM aplikasi Electron juga dapat ditingkatkan dengan bantuan ini, meskipun perubahan yang diperlukan untuk menerapkannya akan jauh lebih besar. Dengan runtime bersama, aplikasi Electron yang menggunakan versi yang sama dapat berbagi beberapa sumber daya di dalam memori.

Bagaimanapun, saya sangat baru di seluruh sumber proyek Electron, jadi maaf jika ada yang tidak jelas, atau jika saya mengulangi sesuatu yang tidak perlu. Saya benar-benar berharap ini akan diimplementasikan, karena ini akan benar-benar membuat Electron menjadi platform yang jauh lebih menjanjikan untuk lebih banyak jenis program. :+1:

@octacian Saya mulai berpikir bahwa PWA adalah pilihan yang lebih baik. Namun, tidak universal – Anda tidak dapat melakukan _semuanya_ menggunakan PWA – tetapi tentu saja untuk hal-hal seperti kalkulator khusus, itu sudah lebih dari cukup.

Sekarang kita tinggal menunggu dukungan PWA di desktop muncul.

Saya juga berpikir bahwa dengan sistem seperti itu, 1- akan lebih mudah untuk mengirim ke sistem tertanam/lebih kecil, dan 2- di masa depan basis sistem operasi seperti elektron dapat dibuat untuk perangkat seluler.

@yasinaydin Sudah ada LG WebOS. (Dulu ada Firefox OS juga, tapi itu dihentikan)

@KeitIG ​​Pak, argumen Anda akan benar-benar layak jika satu-satunya masalah dengan Electron adalah ukurannya. Memiliki program yang sedikit lebih besar tetapi menyederhanakan kompleksitas dan kemungkinan kegagalan bagi pengembang (kami tidak dapat menyangkal bahwa Electron hebat dalam memberi pengembang cara standar untuk membangun aplikasi tanpa banyak ruang untuk mengacaukan) akan luar biasa. Sayangnya, menggunakan versi pustaka yang terpisah untuk setiap aplikasi juga berarti peningkatan penggunaan RAM, dan masalah keamanan terdistribusi (dan lebih sulit untuk diperbaiki). Saya telah menjelaskan ini lebih baik dalam masalah duplikat saya, tetapi singkatnya saya benar-benar berpikir perpustakaan runtime bersama Anda dapat memperbarui sendiri dan berbagi di antara berbagai aplikasi Electron (yang akan dikirimkan dalam versi "lite" juga, seperti ketika beberapa pengembang digunakan untuk mendistribusikan file Java untuk digunakan pada JVM Anda dan dibundel .exe s) akan benar-benar menjadi pemecah kesepakatan untuk Electron, dan sementara saya mengerti bahwa itu mungkin akan menjadi pekerjaan yang sangat berat, itu membuat saya sedih bahwa itu belum ada dalam rencana pengembang. Mari berharap mereka melakukannya di masa depan.

@dre-hh Sementara saya mengakui niat baik dari proposal Anda, itu, antara lain, terlalu membatasi. Misalnya, saya telah mengembangkan aplikasi elektron komersial untuk perusahaan saya, dan digunakan di lingkungan yang sangat diatur (tidak ada konektivitas Internet, persyaratan untuk kemampuan penelusuran / audit, dll.). Pelanggan kami tidak dapat mengizinkan kami melakukan hal-hal seperti memperbarui perangkat lunak secara otomatis. Ini adalah dunia yang sangat berbeda dari aplikasi web biasa untuk massa. Peramban yang selalu hijau dan pemasangan otomatis pembaruan keamanan OS, menurut pendapat saya, adalah ide yang bagus untuk kebanyakan orang dalam banyak kasus, tetapi maksud saya adalah bahwa mereka tidak cocok di mana-mana. Terkadang risiko gangguan yang disebabkan oleh perubahan perangkat lunak jauh lebih besar daripada risiko yang terkait dengan menjalankan versi perangkat lunak yang kedaluwarsa, terutama di lingkungan yang terkendali di mana teknik mitigasi keamanan lainnya diterapkan. Oleh karena itu mengambil tindakan ekstrem seperti memblokir eksekusi aplikasi menggunakan versi elektron yang kedaluwarsa (atau benar-benar, perpustakaan apa pun) bukanlah solusi yang ideal, jika solusi sama sekali. (Selain itu, administrator sudah memiliki banyak kontrol untuk membatasi program apa yang dapat dijalankan, sehingga mereka dapat mengimplementasikannya tanpa fitur OS baru.)

Selain itu, seperti kebanyakan masalah keamanan, sebagian besar masalah berasal dari pengembang yang tidak menyadari risikonya atau telah memilih, untuk alasan apa pun (misalnya kurangnya waktu), untuk tidak mengikuti panduan keamanan untuk alat yang mereka gunakan. (misalnya Keamanan, Kemampuan Asli, dan Tanggung Jawab Anda ) Kami sebagai pengembang semua perlu melakukan bagian kami dalam mengambil tanggung jawab atas kualitas (termasuk keamanan) pekerjaan kami.

Akhirnya, saya pikir adalah suatu kesalahan untuk melihat ke entitas perangkat lunak komersial, seperti Microsoft, untuk mengatasi masalah ini. Ini sebagian karena, seperti yang baru saja disebutkan, kami tidak dapat mengharapkan untuk menghasilkan aplikasi yang aman melalui pengembang yang tidak sadar akan keamanan. Lebih penting lagi, setidaknya menurut pendapat saya, adalah salah satu hal indah tentang Electron adalah sifatnya yang open-source dan multi-platform, yang biasanya bukan prioritas utama bagi vendor perangkat lunak komersial. Kemajuan yang dipikirkan dengan matang dan sukses kemungkinan besar akan membutuhkan beberapa tingkat konsensus dan upaya dari seluruh komunitas pengembang. Tentu saja, kontribusi dari entitas komersial, tentu saja, dihargai.

@jacobq Jika Anda tidak tahu, Microsoft adalah pemilik Electron.

Jika Anda tidak tahu, Microsoft adalah pemilik Electron.

@Jop-V Tolong tambahkan kutipan untuk ini; Saya tidak berpikir itu benar. Halaman depan electronjs.com mengatakan:

Electron adalah proyek open source yang dikelola oleh GitHub dan komunitas kontributor yang aktif.

Microsoft adalah konsumen Electron (menggunakannya dalam produk seperti Visual Studio Code) dan (saya kira) juga merupakan kontributor, tetapi mereka tidak memiliki kepemilikan. File lisensi tidak menyebutkan Microsoft dan artikel Wikipedia juga tidak menyarankan bahwa mereka memiliki posisi kepemilikan.

@jacobq Microsoft akan mengakuisisi GitHub jadi jika Electron saat ini dikelola oleh GitHub, itu akan segera dikelola oleh Microsoft sejauh yang saya tahu.

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

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

Microsoft mengakuisisi Github tidak berarti apa-apa bagi Electron. Github masih/akan tetap menjadi perusahaan yang terpisah, dengan produk dan proyeknya sendiri. Saya tidak melihat Microsoft mengambil alih kepemilikan Electron, sama seperti saya tidak melihat Microsoft mengambil kepemilikan Atom.

Saya pikir perdebatan ini tidak benar-benar membantu titik awal masalah ini.

https://github.com/GoogleChromeLabs/carlo

Carlo terlihat cukup menarik. Saya mengambilnya untuk putaran dan itu sangat intuitif. Adakah yang pernah bereksperimen dengan pkg ?

Mengapa semua proposal untuk mengurangi pembengkakan hard drive dan memori pengguna akhir tidak pernah dikerjakan? Ini adalah ide fantastis yang berusia 4 tahun dan masih sebatas ide. Saya tidak mengerti mengapa hal-hal semacam ini tidak menjadi prioritas utama proyek

@danielo515 karena alih-alih membuat proyek rajin lainnya, ada https://github.com/GoogleChromeLabs/carlo#q -can-a-node-app-using-carlo-be-packaged-as-a-desktop-app

Apa yang sedang Anda bicarakan? Ini sudah merupakan proyek yang sangat besar. Ini juga yang paling luas dan digunakan, jadi menunjuk orang ke proyek yang berbeda untuk fitur yang seharusnya menjadi bagian dari yang satu ini sepertinya tidak benar bagi saya.
Juga, Carlo ini adalah pendekatan yang berbeda, mereka menggunakan Chrome yang Anda instal, jadi ini tidak seperti versi daemon dari Electron .

Saya tidak mengerti mengapa hal-hal semacam ini tidak menjadi prioritas utama proyek

Karena mewujudkannya itu sulit (seperti "sangat" sulit).

Jika Anda tidak senang (yang benar-benar dapat dimengerti), jangan ragu untuk membayar Electron dan mengirimkan PR.

Jangan salah paham, jika ada solusi mudah untuk masalah ini, saya yakin itu sudah diterapkan.

@danielo515

... mengarahkan orang ke proyek berbeda untuk fitur yang seharusnya menjadi bagian dari yang satu ini sepertinya tidak benar bagi saya.

Saya pikir intinya adalah bahwa setiap proyek memiliki kekuatan dan kelemahannya, dan Carlo sangat cocok untuk kasus dengan ruang terbatas. Untuk kasus penggunaan saya, ukuran aplikasi 100MB baik-baik saja, jadi meskipun saya ingin melihat fitur ini, fitur elektron lainnya jauh lebih penting bagi saya.

@jacobq Ya, Anda benar—kasus penggunaan yang berbeda memerlukan alat yang berbeda.

Jika ada orang lain yang tertarik, saya membuat daftar alat serupa untuk mengembangkan aplikasi js di desktop.

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

Saya hanya tidak menggunakan Electron karena saya tidak mampu memperbarui lusinan aplikasi 100MB - dan Anda tahu bagaimana aplikasi perlu diperbarui (saya punya pendapat lain tentang hal itu tetapi membagikannya tidak akan membantu).
Apa yang saya sangat suka tentang pendekatan carlo adalah ide untuk menggunakan browser yang diinstal.
Lebih bagusnya lagi, tentunya carlo bisa menggunakan browser apa saja yang tersedia, tidak hanya chromium, karena dalang juga bisa mengelola browser lain. Di OSX Anda akan menelurkan Safari, di linux epiphany(webkitgtk) atau firefox, dll...
Jadi sebenarnya untuk mendapatkan aplikasi Anda hanya perlu menginstal nodejs dan aplikasi Anda.
Sekarang pertanyaannya adalah: seberapa bagus pkg dalam menggunakan lib yang diinstal sistem, dan addons asli?
Misalnya jika saya harus mengemas aplikasi yang sedang saya kembangkan, saya memerlukan postgresql, sharp (dan vips), webkitgtk, dan exiftool. Saya ingin dapat mendistribusikan aplikasi hanya untuk pengguna linux debian, fedora, atau ubuntu. Saya ingin pergi dengan "bundel gila" dan bukannya memanfaatkan kerja keras yang dilakukan oleh distribusi tersebut, gratis.

@kapouer ... gunakan browser yang diinstal ...

Meskipun secara teori, ide yang bagus itu menghasilkan peningkatan kesulitan dalam pengkodean aplikasi di sisi web karena Anda sekarang harus fokus pada dukungan untuk banyak browser dan browser tempat mereka kembali mungkin terbatas pada apa yang ingin Anda lakukan seperti yang mereka lakukan. tidak memiliki dukungan penuh untuk hal-hal seperti yang dapat Anda temukan di Chromium. Anda juga mengandalkan pengguna untuk memastikan browser mereka mutakhir dan beberapa vendor browser tidak merusak aplikasi Anda dengan pembaruan.

Banyak pengguna telah menyiasati pembaruan besar-besaran 50 Mb dengan beralih ke pembaruan delta atau meminta manajer paket hanya memperbarui file .asar atau folder sumber daya. Dan hanya melakukan pembaruan Elektron besar bila diperlukan. Inilah yang kami lakukan di perusahaan kami dan itu berhasil dengan baik.

Dari sudut pandang pengguna yang naif, Menggunakan shell aplikasi Electron sebagai Shared Runtime akan membuatnya sangat mudah untuk didistribusikan dan digunakan. Untuk Mis. Dengan 5 aplikasi elektron dalam satu sistem, Anda memiliki 5 instance shell aplikasi dan ukurannya sekitar 300MB, bukan?

Saya sangat percaya elektron adalah masa depan UX desktop dan ini akan menjadi langkah besar (lihat .NET Runtime -- mungkin perbandingan yang buruk, tapi, keren kan?) untuk membawa teknologi web lebih kuat.

Electron sudah memiliki runtime untuk pengembangan, bukan? "elektron." perintah, maksudku. Mengapa tidak menggunakannya kembali untuk sisi pengguna?

Untuk menangani beberapa aplikasi tergantung pada versi Electron yang berbeda, Anda dapat menggunakan pendekatan yang digunakan inti .NET. Cukup instal beberapa versi runtime secara berdampingan, dan minta aplikasi mendeklarasikan versi minimum (atau maksimum) yang mereka butuhkan.

Saya telah membuat peluncur bukti konsep: https://github.com/ProPuke/electron-shared

Dapat dieksekusi tunggal, berukuran di bawah 1MB. Berikan direktori aplikasi atau paket asar dan itu akan memeriksa persyaratan versi elektron Anda di package.json devDependencies Anda dan mengunduh/menjalankan dengan versi yang benar.

Waktu proses elektron disimpan di AppData\Local\Local\electron-shared (windows) .cache/electron-shared (linux) Library/Application Support/electron-shared (mac) sehingga dapat dibagikan antar aplikasi.

Tanpa path yang ditentukan maka secara otomatis akan menjalankan direktori app atau app.asar jika ada; Jadi Anda dapat mendistribusikan aplikasi Anda hanya dengan file ini dan app.asar . Atau ini dapat dikaitkan dengan file .asar dan hanya asar yang dapat didistribusikan.

Ia juga memiliki beberapa parameter baris perintah, termasuk --downloadOnly dan --silent sehingga dapat dipanggil dari dalam penginstal selama proses penyiapan.

Itu tidak menangani pembaruan otomatis (hanya mengunduh jika versi Electron yang kompatibel belum tersedia di mesin Anda), tetapi ini dapat dilakukan secara berkala saat peluncuran, atau dengan layanan latar belakang (selama runtime ditempatkan di tempat yang tepat ia akan menemukan dan menggunakan yang terbaru saat aplikasi diluncurkan).

Mengetahui kapan harus menghapus salinan lama runtime bisa jadi rumit. Mereka mungkin menumpuk seiring waktu. Kami perlu melacak aplikasi terinstal mana yang menggunakan versi mana (dan dengan demikian mana yang tidak lagi diperlukan) atau mungkin hanya menyimpan tanggal yang terakhir digunakan untuk setiap versi runtime dan menghapusnya secara otomatis jika belum digunakan dalam beberapa saat.

Pokoknya, bukti konsep/proposal. Apakah hal seperti ini menyelesaikan masalah? Apakah saya melewatkan sesuatu yang mencolok dan jelas?

Saya mencoba berbagi elektron @ProPuke dan saya dapat menjalankan demo mulai cepat elektron . Tetapi saya tidak dapat menjalankan aplikasi apa pun yang dijelaskan di Situs web electronjs ( karena sebagian besar aplikasi menggunakan beberapa skrip shell untuk memulai aplikasi dan bukan hanya package.json, seperti yang saya pahami). Tapi saya percaya _proof of concept/proposal_ ini bisa menjadi petunjuk untuk upgrade besar berikutnya.

Saya punya ide. elektron Karena saat ini mendukung perintah "jalur elektron.exe". Saya pikir Anda dapat membukanya dengan memanggil beberapa asar dari baris perintah. Saat ini, saya hanya sebuah ide. Saya harap seseorang dapat melakukannya, karena saya baru menyentuh software ini.
_____________ versi terjemahan bahasa Mandarin__________
Saya punya ide. Karena saat ini electron mendukung perintah “electron.exe path”. Saya pikir itu bisa dibuka dengan menggunakan baris perintah untuk memanggil banyak asar. Saya hanya sebuah ide saat ini, saya harap seseorang dapat melihatnya, karena saya baru saja terlibat dalam perangkat lunak ini.

Setelah sepintas melihat seluruh percakapan (dan diskusi lain seperti Beberapa "aplikasi"), saya akan meringkas - memanggil banyak asar secara asli alih-alih memulai dengan beberapa binari memiliki sejarah panjang, tetapi tidak didukung . Tetapi default_app elektron diimplementasikan menggunakan baris perintah (mungkin, saya tidak tahu untuk saat ini). Saya pikir memanggil cmd melalui elektron (tampaknya mungkin) harus dapat mencapai kompatibilitas fungsi ini.
Melihat sepintas semua percakapan (dan diskusi lain, seperti Beberapa "aplikasi"), saya menyimpulkan bahwa panggilan asli ke beberapa Asar alih-alih beberapa binari dimulai, yang memiliki sejarah panjang, tetapi tidak didukung. Tapi default_app Electron adalah implementasi yang memanfaatkan baris perintah (dan, mungkin, saya tidak tahu untuk sementara waktu).Saya ingin memanggil cmd melalui elektron (seolah-olah saya bisa) harus dapat mencapai bilah kompatibilitas fitur ini.

Dalam skenario terburuk, Anda harus membuat file .bat atau yang setara untuk OS non-windows, dan menjalankannya dari Electron.

Tautan yang mungkin berguna:

https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options
https://www.freecodecamp.org/news/node-js-child-processes-everything-you-need-to-know-e69498fe970a/

9718

https://stackoverflow.com/questions/50491092/execute-a-cmd-line-with-electron-angular
https://github.com/martinjackson/electron-run-shell-example

Tampaknya hanya ketika tidak ada app.asar atau folder app adalah elektron perintah. jalur exe valid

Oh, jadi Anda harus memiliki elektron untuk menjalankan jalur exe di dalam elektron yang digunakan untuk mengatur semua itu. Masih lebih baik daripada instalasi elektron untuk setiap aplikasi yang digunakan. Anda hanya memerlukan satu instalasi elektron untuk setiap versi elektron yang dibutuhkan aplikasi Anda. Anda mungkin perlu membuat ekstensi terpisah yang merupakan arsip zip yang diganti namanya yang berisi aplikasi yang kami coba jalankan dan file dengan versi yang direkomendasikan (akan segera menjalankannya), versi yang kompatibel (akan menanyakan apakah akan menjalankan atau instal versi yang direkomendasikan, dan juga unduh versi Electron yang direkomendasikan di latar belakang), atau hanya akan menampilkan bilah kemajuan pengunduhan, untuk versi yang direkomendasikan untuk diunduh.

Atau saya salah memahami sesuatu.

Idenya mungkin sama: karena kelelawar saat ini mudah diucapkan, ambil contoh, kontennya adalah electron.exe app1.asar, setelah dieksekusi, electron membuka konten app1.asar. Itu mungkin cara kerjanya, tetapi ketika Anda menulis kalimat berikutnya, electron.exe app2.asar, di kelelawar, Anda hanya dapat melakukannya ketika elektron app1.asar berakhir. Dan ketika kelelawar dimatikan, elektron dimatikan. Tapi saya menulis electron.exe app3.asar|electron.exe-v atau electron.exe app3.asar|start, dan seterusnya. Ketika saya menutup kelelawar, elektron dapat bertahan, tetapi saya tidak dapat melanjutkan untuk membuka asar lainnya. Saya pikir program yang berdiri sendiri ini mungkin lebih baik daripada yang ini, karena kelelawar masih agak terbatas.

Tidak jika Anda menggunakan folder sementara.

Anda memiliki versi (diarsipkan atau tidak diarsipkan) di folder electron_versions, dari mana Anda menggunakan versi yang direkomendasikan atau versi terbaru yang kompatibel yang telah Anda unduh dengan menyalin versi yang Anda gunakan ke folder sementara, dan setelah Anda menyelesaikannya, Anda hapus foldernya.

Jalur file yang disimpan secara lokal akan berada di folder elektron atau di sebelah file yang Anda gunakan. Jika Anda menggunakannya dari arsip yang berisi hal-hal yang saya sebutkan dalam 24 jam terakhir, maka Anda harus memindahkan file data yang disimpan kembali ke arsip, atau tidak memindahkannya sama sekali sebelum Anda menghapus folder instan elektron sementara itu.

SSD？

???

Alasan untuk menghapus folder elektron sementara adalah karena aplikasi secara teoritis dapat mengubah file instalasi elektron yang mereka jalankan, dan sesuai dengan desainnya. Maksud saya, arsip dapat berisi file dan folder yang perlu ditulis atau ditimpa di dalam instalasi elektron sementara.

Jadi setelah instalasi digunakan, itu dapat diperlakukan sebagai rusak oleh aplikasi yang dijalankannya, sehingga tidak dapat didaur ulang, dan dengan demikian harus dihapus. Namun, versi dari mana instalasi yang saat itu rusak digunakan sebagai basis masih utuh, di folder electron_versions dari aplikasi runtime-electron yang kami coba buat.

Sebenarnya, jika arsip dengan ekstensi yang berbeda, yang saya sebutkan sebelumnya, adalah hanya-baca, data yang digunakannya dapat dipindahkan ke %appdata%, secara teoritis. Jadi aplikasi yang berjalan di dalam runtime-mode-electron yang kami coba buat akan benar-benar portabel (mandiri), dan dengan demikian menyalin file itu akan cukup untuk membawa konfigurasi aplikasi itu bersama Anda.

Tetapi kita mungkin juga perlu menambahkan fungsi pembaruan untuk tipe file itu, yang akan menjadi instalasi elektron lain yang akan menyalin dan menimpa file dari file instalasi baru ke salinan file instalasi lama, dan mengembalikan file instalasi baru dengan data yang dimilikinya. Semuanya bisa otomatis dilakukan, jika ada link download di file yang digunakan oleh runtime-mode-electron yang kita coba buat.

Setelah itu siap, jika Anda ingin bekerja lebih keras, Anda bahkan dapat menambahkan klien git untuk memperbarui aplikasi, meskipun itu mungkin memerlukan penggunaan github dan bitbucket untuk meng-host arsip file yang dikompilasi.

Anda dapat menggunakan file unduhan "curl,wget, aria2c", dan pengguna tidak perlu menginstal git，oh，Anda perlu menggunakan "gzip,7z"unpack zip。

Saya membuat alat electron-runtime yang bekerja mirip dengan electron-builder . Ini hanya menggabungkan file app.asar dengan skrip sh sederhana (nantinya ini akan menjadi UI untuk menunjukkan kemajuan unduhan Electron). Saat ini hanya berfungsi untuk macOS.

Saat menjalankan aplikasi yang dikemas dengan electron-runtime Ini pada dasarnya mengunduh versi utama Electron yang sesuai, tetapi yang terbaru dalam kasus minor dan patch, karena perubahan putus dari Electron hanya terjadi dalam peningkatan versi utama.

Aplikasi electron-quick-start hanya 62 KB, tangkapan layar:

Jika Anda tertarik, tinggalkan bintang, PR, atau masalah.

Saya telah memperbarui paket sedikit, yang dapat dibangun menggunakan electron-builder ( Berikut dijelaskan cara kerjanya ). Jadi sekarang Anda bahkan dapat membuat Kode Visual Studio dengannya! (tetapi masih hanya di macOS).

Saya berhasil merilis versi pertama electron-global ! (Saya mengubahnya, karena electron-runtime telah diambil). Anda dapat membangun aplikasi Anda menggunakan paket npm saya dengan electron-builder . Saya juga telah menambahkan UI dengan bilah kemajuan untuk menunjukkan kemajuan unduhan Elektron. Saya harap ini menjadi lebih populer untuk membuat Electron lebih baik.

Maaf, saya menggunakan sistem Windows, dan saya tidak punya uang untuk menggunakan MacOS. Tapi saya yakin proyek Anda akan sangat sukses.

@nwdxlgzs Mendukung Windows, macOS dan Linux...

Saya pikir proyek ini hanya mendukung MAC.
Saya akan meluangkan waktu untuk mencoba proyek hebat ini.

Terima kasih telah membuatnya dan membuat kami tetap up-to-date!
Saya juga menggunakan Windows.
Saya akan melihat kode ketika saya mendapatkan perubahan.

Nah, bagaimana kalau mengintegrasikan electron-global upstream dan menjadikannya default baru