Electron: अपेक्षित ऐप बंडल आकार?

यह अपेक्षित आकार है, इसे छोटा करने का कोई उपाय नहीं है।

क्या वाकई इतना बड़ा होने की उम्मीद है? मेरी बंडल्ड विंडो और लिनक्स बिल्ड बहुत छोटे हैं, और इलेक्ट्रॉन फ्रेमवर्क फ़ोल्डर को देखते हुए, इलेक्ट्रान फ्रेमवर्क फ़ाइल की तीन प्रतियां हैं, प्रत्येक पर एक:

सामग्रीफ्रेमवर्कइलेक्ट्रॉन फ्रेमवर्क।फ्रेमवर्क
ContentsFrameworksElectron Framework.frameworkVersionsA
ContentsFrameworksElectron Framework.frameworkVersionsCurrent

क्या इन्हें प्रतीकात्मक लिंक माना जाता है?

विंडोज और लिनक्स कितने छोटे बनते हैं?

मैं भी इस बारे में सोच रहा हूं। मेरे इलेक्ट्रॉन ऐप के आकार यहां दिए गए हैं:

ओएसएक्स - 117.3 एमबी
 linux32 - 60.3 एमबी
 linux64 - 55.2 एमबी
 जीत ia32 - 47.8 एमबी
 विन x64 - 66.2 एमबी

धन्यवाद!

क्या भविष्य में रिलीज में ढांचे के आकार को कम करने की कोशिश करने की कोई योजना है? इससे छोटे ऐप्स के लिए इलेक्ट्रॉन का उपयोग करना उचित ठहराना मुश्किल हो जाता है (जहां ऐप का आकार स्वयं इलेक्ट्रॉन के आकार से छोटा हो जाएगा)।

मैं पुष्टि कर सकता हूं कि मेरे इलेक्ट्रॉन ऐप बंडल @davefedele के समान आकार के हैं।

आप अपने ऐप को ज़िप कर सकते हैं और यदि आप electron-packager का उपयोग कर रहे हैं तो आप कुछ नोड मॉड्यूल को अनदेखा कर सकते हैं जिनकी आपको ऐप के चलने पर आवश्यकता नहीं है, इससे यह थोड़ा छोटा हो जाता है। उदाहरण के लिए मेरे पास 37 एमबी ज़िप्ड इलेक्ट्रॉन ऐप है (नोट विंडोज संस्करण बहुत बड़ा है क्योंकि इसमें गिट की एक प्रति है)।

लेकिन इलेक्ट्रॉन में हमेशा क्रोम का एक बड़ा हिस्सा रहेगा, इसलिए केवल इतना ही किया जा सकता है। इलेक्ट्रॉन ही अभी ~ 33MB है।

ओएस एक्स संपीड़ित अन्य प्लेटफार्मों के समान आकार का है, जिसका शायद मतलब है कि आकार मापने के लिए आप जिस ऐप का उपयोग कर रहे हैं वह शायद सिम्लिंक की गलत व्याख्या कर रहा है?

मेरे मामले में मैं एक इलेक्ट्रॉन-बॉयलरप्लेट का उपयोग कर रहा हूं जो electron-packager उपयोग नहीं करता है और मेरा इलेक्ट्रॉन ऐप फ़ोल्डर एक पायथन स्क्रिप्ट के साथ ज़िपित हो जाता है और aws s3 के माध्यम से वितरित किया जाता है। तो मेरा पहला हालांकि यह था कि सिम्लिंक का सम्मान नहीं किया गया था जब संपीड़ित किया गया था (बजाय फ़ाइल आकार की गलत व्याख्या की जा रही है)।

मुझे इस पर गौर करना होगा, क्या कहीं मौजूद सिम्लिंक की सूची है? मेरे पास मैक कंप्यूटर तक बहुत सीमित पहुंच है (मैं प्रत्येक प्लेटफॉर्म के लिए अपना ऐप पैक करने के लिए सीआई सर्वर का उपयोग करता हूं)।

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

मैं आखिरकार कल इस पर गौर करने में सक्षम था, और वास्तव में मेरी समस्या सिम्लिंक को संरक्षित नहीं किए जाने के कारण हुई थी। तो मेरे आवेदन का आकार ~ 110 एमबी से ~ 45 एमबी तक काफी कम हो गया।

@carlosperate क्या आप सिम्लिंक कैसे तय किए?

खैर, इस बात पर ज़ोर देना ज़रूरी है कि मैं electron-packager का उपयोग नहीं कर रहा हूँ। मेरे पास एक अजगर "बिल्ड स्क्रिप्ट" था (वही स्क्रिप्ट विंडोज़, लिनक्स और ओएस एक्स में चलती है) जो मेरे इलेक्ट्रॉन ऐप से स्वतंत्र अन्य सामान का निर्माण करेगी, फिर मैक पर चलने पर यह सब कुछ सामान्य ओएस एक्स ऐप बंडल निर्देशिकाओं में कॉपी कर देगा, और अंत में सब कुछ एक ही फाइल में ज़िप करें।

इसलिए, मेरे विशिष्ट मामले में मेरी स्क्रिप्ट के साथ दो मुद्दे थे, मैं सहानुभूति का सम्मान किए बिना इलेक्ट्रॉन फ़ाइलों की प्रतिलिपि बना रहा था (ठीक करने में बहुत आसान), और फिर पायथन में zipfile मॉड्यूल सिम्लिंक का सम्मान नहीं कर रहा था, जो उतना आसान नहीं था जितना मुझे उम्मीद थी। यदि आप समस्या के समाधान के लिए Google हैं, तो आपको अजीब कार्यान्वयन वाले कुछ लेख मिलेंगे जो वास्तविक स्पष्टीकरण की तुलना में जादू के करीब थे, इसलिए कुछ समय बाद इसे काम पर लाने की असफल कोशिश करने के बाद मैं बस एक उपप्रोसेस चला रहा था जो ओएस एक्स निष्पादित करता है zip सहानुभूति के सम्मान के लिए आवश्यक झंडे के साथ सीएलआई कमांड।

FWIW, OS X में वितरण के लिए Linux पर एक ज़िप बनाते समय, आपको सिम्लिंक को सही ढंग से संभालने के लिए -y पैरामीटर का उपयोग करना होगा:

$ zip -r -y app.zip app

#स्लैक ने क्या किया है? उनका ऐप इतना छोटा क्यों है?
ज़िप संग्रह फ़ाइल 24.6 एमबी है।

विंडोज़ और लिनक्स संस्करण कमोबेश मेरी अपेक्षा के अनुरूप हैं, मुझे आश्चर्य है कि उनका OSX संस्करण इतना छोटा कैसे है।

पिछली बार मैंने चेक किया था कि स्लैक मैक साइड के लिए मैकगैप का उपयोग कर रहा था

सूची में http://electron.atom.io/#built -on-electron स्लैक है।

हां, स्लैक के विंडोज और लिनक्स ऐप इलेक्ट्रॉन पर बनाए गए हैं, लेकिन मैक ऐप मैकगैप का उपयोग करता है।

@joshaber मुझे लगता है कि आप सही हैं। स्लैक मैक ऐप केवल ~ 36 एमबी का है।

क्या आप लोग जानते हैं कि अंतिम बंडल आकार को कम करने के लिए इलेक्ट्रॉन की कोई योजना है या नहीं? यह अविश्वसनीय होगा।

क्या आप लोग जानते हैं कि अंतिम बंडल आकार को कम करने के लिए इलेक्ट्रॉन की कोई योजना है या नहीं? यह अविश्वसनीय होगा।

आप क्रोमियम, Node.js, V8, आदि से केवल इतना ही निकाल सकते हैं और अभी भी एक कार्यशील उत्पाद है। दुर्भाग्य से चूंकि सब कुछ काम करने के लिए पैच किया गया है, इसलिए इसे आकार में कटौती करने के लिए प्रत्येक के स्टैंडअलोन संस्करणों का उपयोग करना उतना आसान नहीं है। मुझे यकीन है कि इलेक्ट्रॉन टीम छोटे आकार को पसंद करेगी। लेकिन आप सिर्फ योजना नहीं बना सकते और इसे पूरा नहीं कर सकते। यह सोचने के लिए समग्र परियोजना पर बहुत ही कास्टिक है कि आप 10-20 मेग्स कोड और संसाधनों को भी हटा सकते हैं और सब कुछ स्थिर चलने की उम्मीद कर सकते हैं।

इतना सच @baconface ... हालांकि एक बात ने मुझे यहां मदद की है: मैं "ऐप" फ़ोल्डर में इलेक्ट्रॉन-प्रीबिल्ट, इलेक्ट्रॉन-बिल्डर और इलेक्ट्रॉन-पैकेजर और उनकी सभी निर्भरताओं जैसे मॉड्यूल डाल रहा था। उन्हें ऐप के package.json से काटकर और फिर से बिल्डिंग ने मुझे बहुत आकार बचाया। मैंने इलेक्ट्रॉन-बिल्डर से दो-पैकेज.जेसन संरचना का उपयोग किया।

@leonelcbraz electron-packager लिए मेरे अनदेखा रेगेक्स से उधार लेने या विचार प्राप्त करने के लिए स्वतंत्र महसूस करें। मैं बिन निर्देशिका में निष्पादन योग्य फ़ाइलें बनाता हूं, असीमित स्रोत फ़ाइलों के लिए एक स्रोत निर्देशिका है, निर्माण के लिए ग्रंट का उपयोग करें, और अन्य चीजें हैं जिनकी मुझे वहां आवश्यकता नहीं थी। अगर मैं किसी प्रोजेक्ट पर काम करता हूं तो मुझे नोड संदर्भ का उपयोग करने की आवश्यकता नहीं है, मैंने अभी nodeIntegration से false और संपूर्ण नोड_मॉड्यूल्स निर्देशिका को अनदेखा कर दिया है। इसने मेरे वितरण आकार को काफी कम कर दिया।

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

इसके अतिरिक्त दो-पैकेज.जेसन संरचना का उपयोग करने की कोई आवश्यकता नहीं है। NPM डेवलपर निर्भरता का समर्थन करता है। आप npm install <package name> --save-dev माध्यम से एक स्थापित कर सकते हैं। फिर आप अपने package.json में देखेंगे कि आपके पास dependencies और devDependencies जिसमें आपकी निर्भरताएं बड़े करीने से अलग हैं। electron-packager लिए अनदेखा रेगेक्स को संशोधित करना जैसे मैंने ऊपर किया था, आप उन्हें अपने ऐप से पूरी तरह से अलग कर सकते हैं फिर भी सामान्य नोड.जेएस वातावरण में काम कर सकते हैं।

संपादित करें: यह इससे भी आसान है!

अच्छा लगता है। साझा करने के लिए धन्यवाद :)

स्लैक में अब मैक क्लाइंट का इलेक्ट्रॉन बीटा है। पुरानी मैक बाइनरी (मैकगैप का उपयोग करके) डिस्क पर 36 एमबी थी। नया मैक बाइनरी (इलेक्ट्रॉन का उपयोग करके) 175MB है। उसमें से 124MB इलेक्ट्रॉन फ्रेमवर्क है।

@NelsonMinar यह बेकार है, साथियों। ऐप साइज के साथ कुछ करने की जरूरत है।

माना।

@baconface इग्नोर रेगेक्स का उपयोग करने से ऐप के आकार को कम करने में बहुत मदद मिली, मैंने मैन्युअल रूप से अधिक नोड_मॉड्यूल्स को भी अनदेखा किया जो वहां थे और मेरा ऐप बिना ठीक चल सकता था, जो मुझे कुल मैक ऐप आकार के लगभग 50 एमबी और विंडोज के लिए लगभग 60 एमबी तक मिला।

@pierreraii खुशी है कि इससे मदद मिली। एक महत्वपूर्ण बात यह है कि NPM3 नोड_मॉड्यूल निर्देशिका के काम करने के तरीके को बदल देता है । परिणामस्वरूप यह तरकीब शायद आपकी उम्मीदों पर खरा न उतरे। हालांकि आप npm i npm<strong i="7">@2</strong> -g का उपयोग करके NPM को संस्करण 2 में डाउनग्रेड कर सकते हैं।

भविष्य में काम पर हमारी परियोजना के लिए हमारा समाधान एनपीएम 3 का उपयोग कर रहा है लेकिन हम जो कुछ भी नहीं चाहते हैं उसे देव निर्भरता के रूप में भेजना चाहते हैं। हम परियोजना स्तर के विपरीत विश्व स्तर पर अपने इलेक्ट्रॉन निर्माण उपकरण स्थापित करते हैं। फिर npm install --only=production साथ केवल आवश्यक मॉड्यूल की स्थापना करना। हालांकि यह ओपन सोर्स प्रोजेक्ट्स के लिए आदर्श नहीं है लेकिन यह हमारे कार्यालय के लिए काम करता है। यह दुर्भाग्यपूर्ण है कि हमारे पास इस तरह का एक अजीब सेटअप है, लेकिन यह संदिग्ध है कि एनपीएम को कभी भी इलेक्ट्रॉन को ध्यान में रखकर डिजाइन किया जाएगा क्योंकि यह एनपीएम पारिस्थितिकी तंत्र में सिर्फ एक ब्लिप है।

हाँ, वेब देवों को शीर्ष में इलेक्ट्रॉन से निपटने के लिए कहना लगभग असंभव हो जाता है। बस एक env के बारे में सोच रहा है जो दोनों हो सकता है ... वर्तमान में मैं अपने इलेक्ट्रॉन ऐप्स को पहले से तैनात सर्वर पर आधारित करता हूं, क्योंकि वे पहले और अन्य सभी के लिए आदर्श रूप से समान निर्भरताओं को साझा कर सकते हैं। अगर असर वास्तविक उपयोगकर्ता एफएस हो सकता है, तो मैं आकार और प्रतिलिपि समस्याओं को हल करने पर विचार करता हूं, खासकर देशी एक्सटेंशन के साथ

@baconface आपको इसके बारे में चिंता करने की ज़रूरत नहीं है। बस अपनी निर्भरताएं सामान्य की तरह स्थापित करें ( dependencies और devDependencies में देव विवरण) और फिर पैकेजिंग चरण के दौरान ( electron-packager यह आपके लिए करता है) बस अपने ऐप फ़ोल्डर की प्रतिलिपि बनाएँ एक अस्थायी निर्देशिका में और चलाएँ।

npm prune --production

यह आपके एनपीएम संस्करण की परवाह किए बिना सभी देव निर्भरताओं को नष्ट कर देगा, जिसके परिणामस्वरूप न्यूनतम आकार संभव है।

आप केवल --production . की तुलना में एक और 40-80+% अधिक हटा सकते हैं

आप केवल --production . की तुलना में एक और 40-80+% अधिक हटा सकते हैं

यदि ऐसा है तो आपकी निर्भरता गलत तरीके से कॉन्फ़िगर की गई है, यदि आपको एक मॉड्यूल को हटाने की आवश्यकता है और prune --production इसे हटा नहीं रहा है तो इसका मतलब है कि इसे उत्पादन निर्भरता के रूप में मान्यता दी गई है। इसे devDependencies ले जाने के परिणामस्वरूप इसे हटा दिया जाएगा।

ओह क्षमा करें, यह कहना भूल गया: यदि आप एक फ़ाइल मास्क बनाते हैं जो रीडमी, लाइसेंस, ... को हटा देता है और अकेले नोड-जिप 100 गुना अधिक उत्पादन करता है

@xblox मैं केवल उन yarn clean चलाने के लिए है जो स्वचालित रूप से आपके लिए इन चीजों को मिटा देती है।

@MarshallOfSound आपको आश्चर्य होगा, खासकर जब आप देशी मॉड्यूल का उपयोग करते हैं। चारों ओर ढेर सारा कचरा। yarn clean दृष्टिकोण एक अच्छा हो सकता है

@MarshallOfSound हर पैसे के लायक अपना फ़ाइल-मास्क कर रहा है, यह हमेशा आश्चर्यजनक है कि कुछ पैकेजों के अंदर क्या है। और यह सिर्फ कुछ किलोबाइट से काफी अधिक है, लेकिन मैं यार्न को साफ देखूंगा। सूचक के लिए धन्यवाद।

@MarshallOfSound, @paulcbetts: के साथ खेलने के बाद yarn clean : यह क्या के साथ संभव है की केवल लगभग 70% साफ उल्लेख फ़ाइल मुखौटा

अगर हम बिना किसी नोड मॉड्यूल निर्भरता के एक हैलो वर्ल्ड एप्लिकेशन लिखना चाहते हैं, तो पैकेजर अभी भी सब कुछ क्यों ताना देता है? अत्याधुनिक समाधान yarn clean , है ना?

मेरा नोड_मॉड्यूल 40 एमबी है और इलेक्ट्रॉन 140 एमबी . है

इलेक्ट्रॉन-बिल्डर और इस फाइल ग्लोब का उपयोग करके मैं अपने डेस्कटॉप ऐप पर लगभग 80% प्राप्त करता हूं

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

बात यह है कि यह वास्तव में आपके द्वारा उपयोग किए जाने वाले मॉड्यूल पर निर्भर है, जिससे इसे बनाए रखने में दर्द होता है!

@farfromrefug यदि आप ओपन सोर्स libs का उपयोग कर रहे हैं तो सावधान रहें अपने ऐप को शिपिंग करें, एक मौका है कि आप जिन पुस्तकालयों का उपयोग कर रहे हैं उन्हें लाइसेंस फ़ाइल को सभी एप्लिकेशन के साथ भेजने की आवश्यकता है और आप उन सभी को अंधाधुंध हटा रहे हैं।

@OmgImAlexis वास्तव में आप सही हैं मुझे लाइसेंस फाइलें रखनी चाहिए। धन्यवाद!

बिलकुल चौकन्ना। electron-packager एक devDependencies में सूचीबद्ध निर्भरताओं को शुद्ध करने के लिए पर्याप्त स्मार्ट है। इसलिए मैंने अपने अधिकांश पैकेज उसमें स्थानांतरित कर दिए और ग्रंट का उपयोग करके एक एकल जेएस फ़ाइल में उपयोग की जाने वाली स्क्रिप्ट को बंडल कर दिया। तो अब अनदेखा करने के लिए मेरा रेगेक्स कुछ इस तरह दिखता है "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|build.js)" । मुझे वही परिणाम देता है लेकिन यह बहुत आसान है और मुझे अपने रेगेक्स में मैन्युअल रूप से निर्भरता पथ जोड़ने की आवश्यकता नहीं है। यहां तक ​​​​कि जिस तरह से यार्न निर्भरताओं को संग्रहीत करता है, उसके साथ भी काम करता है।

मैंने हाल ही में https://github.com/electron/simple-samples.git से सीखने के उद्देश्य के लिए उदाहरण परियोजना का क्लोन बनाया था
इलेक्ट्रॉन-पैकेजर C:userlearningnodeclonedAppsimple-samplesactivity-monitor cpu --platform=win32 --arch=x64 --ignore="node_modules"

मुझे आश्चर्य हुआ कि एक साधारण ऐप के लिए बंडल का आकार 132 एमबी है।
क्या बंडल के आकार को कम करने का कोई तरीका है?

मैंने आपके निष्पादन योग्य पर UPX का उपयोग करने का सुझाव दिया होगा, जो क्रॉस-प्लेटफ़ॉर्म है, कई आर्किटेक्चर का समर्थन करता है और उपयोग में आसान है, लेकिन दुर्भाग्य से ऐसा लगता है कि इलेक्ट्रॉन की टीम इस पर झुकना पसंद नहीं करती है।
(पहले ही अनुरोध किया जा चुका है: https://github.com/electron/electron/issues/5506)

अन्यथा, मेरे परीक्षण ने NW.js को UPX (~ अंतिम आकार में 60% कम) के साथ संपीड़ित करके अच्छी तरह से काम किया, हालांकि मैंने कोशिश नहीं की अगर यह अभी भी नवीनतम संस्करण के साथ काम करता है ...
तो अगर आकार मायने रखता है, तो शायद आप इसके बजाय इसके विकास पर ध्यान केंद्रित कर सकते हैं?

मैं ले जाकर 52MB करने के लिए अपने ज़िपित OSX वितरण आकार प्राप्त करने में सक्षम था electron करने के लिए और काफी किसी भी अन्य गैर क्रम पैकेज devDependencies में package.json , चल rm -rf node_modules और फिर npm install --production ।

ऐप की पैकेजिंग करते समय, electron-packager परियोजना के node_modules लापता electron निर्भरता की शिकायत करेगा। आप निम्न ध्वज को electron-packager प्रदान करके उसके आसपास काम कर सकते हैं:

--electron-version=1.7.11

स्थानापन्न 1.7.11 अपने वांछित के साथ electron-packager संस्करण।

@eladnava जानकारी प्रदान करने के लिए धन्यवाद। मैं आपके द्वारा प्रदान किए गए चरणों की जांच करूंगा। जब मैं एप्लिकेशन को डीएमजी में परिवर्तित करता हूं तो इसका आकार 53 एमबी होता है।

मैं पिछले सभी संदेशों को नहीं जानता/पढ़ा नहीं, इसलिए कृपया मुझे बताएं कि क्या यह पहले ही कहा जा चुका है।

क्या इलेक्ट्रॉन ढांचे को स्वयं अलग करना और केवल ऐप्स को शिप करना संभव है?

जहां तक ​​​​मैं समझता हूं, जिस तरह से इलेक्ट्रॉन ऐप्स शिप करते हैं वह fw शामिल है। ऐसा लगता है कि इसमें शामिल जेआरई के साथ जावा ऐप शिपिंग करना है।

क्या ओएस में इलेक्ट्रॉन ढांचा स्थापित करना संभव है ताकि उस संस्करण का उपयोग करने वाले सभी ऐप्स उपयोग कर सकें?

@eladnava आपको एहसास है कि लक्ष्य-मशीन पर इलेक्ट्रॉन स्थापित नहीं होने पर आपका ऐप नहीं चलेगा?

@ fab1an : मुझे लगता है कि @yasinaydin इसे समझता है। वह एक इलेक्ट्रॉन सामान्य रनटाइम चाहता है जिसे उपयोगकर्ता अपने सभी इलेक्ट्रॉन-उपयोग अनुप्रयोगों के लिए स्थापित कर सकते हैं। इस पर पहले से ही इलेक्ट्रॉन/इलेक्ट्रॉन#673 में चर्चा की जा रही है, वर्तमान में इसका कोई समाधान नहीं है।

@ js-choi @ fab1an मुझे पूरी तरह से यकीन नहीं है कि यह कैसे काम करता है, लेकिन मुझे लगता है कि इलेक्ट्रॉन electron-packager में पहले से बंडल में आता है, Electron Framework.framework भीतर जो पैकेज्ड ऐप में शामिल है।

इसलिए, आपके ऐप के node_modules electron को भी बंडल करने का कोई कारण नहीं है। इसके अलावा, मेरे काम करने के दृष्टिकोण के लिए लक्ष्य मशीन पर npm electron पैकेज स्थापित करने की कोई आवश्यकता नहीं है।

इलेक्ट्रिनो अपनी तकनीक का उपयोग करके केवल 167 kB तक का 115 एमबी इलेक्ट्रॉन ऐप बनाने में सक्षम था। मुझे लगता है कि इस तकनीक को इलेक्ट्रॉन में एकीकृत किया जाना चाहिए, एक 100 एमबी हैलो वर्ल्ड ऐप "हैलो वर्ल्ड" प्रदर्शित करने के लिए सामान्य आकार नहीं है: +1:

@spaceywolfi चूंकि

बेस बाइनरी आकार को ~ 50 एमबी तक कम करने के लिए आप मेरे द्वारा बताए गए ट्रिक के साथ जाने का प्रयास कर सकते हैं।

@eladnava समझाने के लिए धन्यवाद!

@eladnava

मुझे पूरी तरह से यकीन नहीं है कि यह कैसे काम करता है, लेकिन मुझे लगता है कि इलेक्ट्रॉन इलेक्ट्रॉन-पैकेजर में पहले से बंडल में आता है, इलेक्ट्रॉन फ्रेमवर्क के भीतर। फ्रेमवर्क जो पैक किए गए ऐप के भीतर शामिल है।

इसलिए, आपके ऐप के नोड_मॉड्यूल के भीतर इलेक्ट्रॉन को बंडल करने का कोई कारण नहीं है। काम के प्रति दृष्टिकोण।

मेरे पास electron और electron-packager मेरे devDependencies । इस तरह मैं अपने package.json में एक स्क्रिप्ट को electron ./dist/js/main.js असाइन कर सकता हूं। तो उदाहरण के लिए npm run launch चलाना मेरे इलेक्ट्रॉन ऐप के इंस्टेंस का परीक्षण करने के लिए तैयार एक अनपैकेज्ड लॉन्च करेगा। इसके अतिरिक्त electron-packager electron लिए सूचीबद्ध संस्करण का उपयोग करेगा, इसलिए आपका पैक किया गया संस्करण आपके इलेक्ट्रॉन के परीक्षण संस्करण के समान है। इसे स्वचालित रूप से आउटपुट से electron और electron-packager भी अलग कर देना चाहिए।

@ बेकनब्रैड

आपकी टिप के लिए धन्यवाद। मैंने अंतिम बाइनरी के node_modules फ़ोल्डर में पैक होने से बचने के लिए विश्व स्तर पर electron और electron-packager स्थापित करना समाप्त कर दिया। मैंने पाया कि electron-packager ने इन निर्भरताओं को अंतिम बाइनरी से स्वचालित रूप से अलग नहीं किया, जिसके परिणामस्वरूप मेरे लिए ~ 100 एमबी का बाइनरी आकार हुआ। विश्व स्तर पर इन दो पैकेजों को स्थापित करने के बाद, बाइनरी आकार ~ 50 एमबी तक गिर गया।

@eladnava यह संभावना इसलिए हुई क्योंकि आपने उन्हें एक निर्भरता के रूप में लिया था न कि एक देव निर्भरता के रूप में। यदि आप npm install packagename --save-dev उपयोग करते हैं तो यह इसे आपके package.json के उचित क्षेत्र में सहेज लेगा। यह आपके node_modules फोल्डर में दिखाई देगा लेकिन पैक होने के बाद इसे हटा दिया जाएगा।

@ बेकनब्रैड

यह वाकई काफी संभव है। लेकिन मुझे लगता है कि चूंकि npm नए संस्करण रूट प्रोजेक्ट node_modules/ फ़ोल्डर में आपकी सभी निर्भरताओं की निर्भरताओं को स्थापित करते हैं, हो सकता है कि इन्हें electron-packager द्वारा अंतिम बाइनरी में बंडल किया जा रहा हो .

क्या आप जानते हैं कि electron-packager उन devDependencies ' निर्भरता को छोड़ने के लिए पर्याप्त स्मार्ट है या नहीं?

@eladnava

क्या आप जानते हैं कि क्या इलेक्ट्रॉन-पैकेजर उन देव-निर्भरताओं की निर्भरता को छोड़ने के लिए पर्याप्त स्मार्ट है?

पुष्टि कर सकता है कि यह devDependencies निर्भरता को छोड़ देता है। भले ही आप एनपीएम या यार्न के नवीनतम संस्करण का उपयोग कर रहे हों।

इसके अलावा आपको फ्रंट एंड डिपेंडेंसी को बंडल करने के लिए गल्प या ग्रंट जैसे बिल्ड सिस्टम का उपयोग करना चाहिए और उन्हें devDependencies में भी सूचीबद्ध करना चाहिए। ऐसा इसलिए है क्योंकि उन्हें अतिरिक्त स्रोत फ़ाइलों या उनके devDependencies साथ शिप किया जा सकता है। मेरे पास केवल dependencies है क्योंकि मुझे इसे पूरी तरह से शिप करने की आवश्यकता है। आपकी स्क्रिप्ट अभी भी नोड संदर्भ में चलना चाहेगी, इसलिए ब्राउज़र संदर्भ में अपनी बंडल स्क्रिप्ट में लोड करने से पहले आपको window.module = module; module = undefined; पर कॉल करने की आवश्यकता होगी। मैं तब यह सुनिश्चित करता हूं कि मेरे पैकेजर के पास इसे अनदेखा विकल्प "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)" । इन सभी चरणों को करने से मूल रूप से अत्यधिक निर्भरता समाप्त हो जाती है या गलती से स्रोत फ़ाइलों या फ़ोल्डरों का निर्माण होता है।

@ बेकनब्रैड

सुझावों के लिए चीयर्स दोस्त!

हाय दोस्तों,

सभी के लिए ऐप के आकार को बहुत कम करने के लिए, सभी के लिए बैंडविड्थ बचाने के लिए, सभी के लिए निर्माण प्रक्रिया को आसान बनाने के लिए, आदि। अनुकूलन/सोच को कुछ नोड_मॉड्यूल को अनदेखा करने से अलग तरीके से किया जाना चाहिए।

एक ही विचार का उपयोग करने के बारे में कैसे जावा और जावा ऐप्स दशकों से सफलतापूर्वक उपयोग कर रहे हैं: "जेआरई" (जो हमारे मामले में "ईआरई" होगा) पर निर्भरता है।

इस तरह, ईआरई को पहले ऐप के लिए मशीन पर विश्व स्तर पर स्थापित किया जाएगा (ईआरई की आवश्यकता की प्रक्रिया को प्रत्येक प्लेटफॉर्म के लिए ऐप इंस्टॉलर द्वारा स्वचालित किया जा सकता है), और फिर हर नया ऐप केवल इस मौजूदा ईआरई का उपयोग करेगा। .

इसके लिए काम करने के लिए ईआरई को ऑटो-अपडेट फीचर और पिछड़ा-संगतता (कोई बीसीबी नहीं!) की आवश्यकता होगी, लेकिन मुझे पूरा यकीन है कि यह छोटा-आश है।

फिर, प्रत्येक इलेक्ट्रॉन ऐप का वजन केवल एक जोड़े एमबी की तरह होगा। उपयोगकर्ताओं के समय की बचत। डेवलपर्स के समय और बैंडविड्थ की बचत और जटिलता का निर्माण।

क्या यह पहले प्रस्तावित किया गया है? अगर ऐसा है तो उसके बारे में कैसे? मुझे लगता है कि यह जाने का एकमात्र और सबसे अच्छा तरीका है।

@RenaudParis मैंने इसे पहले और शायद कुछ और प्रस्तावित किया था, लेकिन मैंने अब तक कोई गंभीर काम नहीं सुना है।

@yasinaydin मैंने उतना ही सोचा, लोगों ने इसके बारे में पहले भी सोचा होगा।

खैर, तब देव टीम से कोई इनपुट? @zcbenz यह इतने सारे लोगों को खुश कर देगा, और इलेक्ट्रॉन भविष्य-सबूत को बड़ा समय बना देगा (क्योंकि चलिए इसका सामना करते हैं: प्रत्येक ऐप के अंदर दो ढांचे को एम्बेड करना छोटे ऐप्स के उपयोग को गंभीरता से सीमित कर रहा है, यह एक नियमित रान है जो चल रहा है वर्षों से)

क्या जेआरई यहां अनुसरण करने के लिए एक महान उदाहरण नहीं है?

@RenaudParis और @yasinaydin , ऐसे कई कारण हैं जिनके कारण इलेक्ट्रॉन की वैश्विक स्थापना कभी नहीं होगी।

सबसे पहले, जंगली में सभी उत्पादन इलेक्ट्रॉन ऐप्स में, शायद उपयोग में इलेक्ट्रॉन के 20+ विभिन्न संस्करण हैं। आप विश्व स्तर पर कौन सा संस्करण चुनना चाहेंगे? यह इस तरह खंडित है क्योंकि इलेक्ट्रॉन का तेजी से रिलीज चक्र होता है और डेवलपर्स नवीनतम क्रोम सुविधाओं तक पहुंच चाहते हैं।

हमारे ऐप्स का परीक्षण केवल इलेक्ट्रॉन के एक संस्करण के साथ किया जाता है और 40 एमबी डाउनलोड के लिए हम इसे किसी अन्य यादृच्छिक अप्रयुक्त संस्करण पर चलाने की अनुमति देने के जोखिम और समर्थन लागत को क्यों चलाएंगे?

निर्माण प्रक्रिया को सभी के लिए आसान बनाएं

कई इलेक्ट्रॉन ऐप देशी मॉड्यूल का उपयोग करते हैं जो कि ज्यादातर मामलों में उपयोग में इलेक्ट्रॉन के विशिष्ट संस्करण के खिलाफ बनाया जाना है। आप इस मुद्दे को कैसे सुलझाएंगे?

इलेक्ट्रॉन का एक वैश्विक संस्करण बनाने के लिए स्वतंत्र महसूस करें जिसका डेवलपर्स उपयोग कर सकते हैं लेकिन मुझे लगता है कि आप पाएंगे कि उपरोक्त कारणों से शायद ही कोई इसका उपयोग करेगा!

@timfish
there are so many reasons having a global install of electron will never happen.
यह इनमें से एक जैसा लगता है: https://www.pcworld.com/article/155984/worst_tech_predictions.html

चूंकि Node/v8 या इलेक्ट्रॉन बायनेरिज़ इतने बड़े नहीं हैं, एक वैश्विक ERE आवश्यकता पड़ने पर एक बार उपयोग करने के लिए लापता घटकों को डाउनलोड कर सकता है। इसके अलावा इन वैश्विक ईआरई के लिए कुछ बंडल लॉजिक को लागू किया जा सकता है, जैसे Node.js 9.x के बजाय अलग Node.js 9.0, 9.1 आदि।

मुझे नहीं पता, लेकिन मुझे नहीं लगता कि चीजों को करने का यह रवैया है... "ओह, यह नहीं किया जा सकता। ओह यह असंभव है। इसका कोई मतलब नहीं है।" इसके बजाय यह होना चाहिए "हम इस एक्स को कैसे पूरा/कामकाज कर सकते हैं?"

@timfish यह दुखद खबर है ... मैं व्यक्तिगत रूप से 40MB फ़ाइल के बारे में ज्यादा परवाह नहीं करता, लेकिन 120MB (जैसा कि मैंने सुना) हालांकि हैलो वर्ल्ड के लिए थोड़ा बहुत है।

सबसे पहले, जंगली में सभी उत्पादन इलेक्ट्रॉन ऐप्स में, शायद उपयोग में इलेक्ट्रॉन के 20+ विभिन्न संस्करण हैं। आप विश्व स्तर पर कौन सा संस्करण चुनना चाहेंगे?

जैसा कि मैंने कहा, पिछड़ी संगतता की आवश्यकता होगी।

डेवलपर नवीनतम क्रोम सुविधाओं तक पहुंच चाहते हैं

इसलिए प्रगतिशील वृद्धि... है ना? किसी भी मामले में, प्रगतिशील वृद्धि भी अनिवार्य नहीं है यदि किसी ऐप को ईआरई के विशिष्ट संस्करण की आवश्यकता हो सकती है, जो वैश्विक ईआरई के अपडेट को ट्रिगर करेगा।

आप इस मुद्दे को कैसे सुलझाएंगे?

यदि कुछ लोगों को विशेष रूप से संकलित मॉड्यूल की आवश्यकता है, तो वे मॉड्यूल के अपने स्वयं के कस्टम संस्करण को एम्बेड करने के लिए स्वतंत्र हैं (जो किसी भी मामले में ईआरई के अंदर उपलब्ध नहीं होगा) और ईआरई का न्यूनतम संस्करण निर्दिष्ट करें। यदि ईआरई को एक नए संस्करण में अपडेट किया गया है, तो मुझे लगता है कि 2 स्पष्ट समाधान हैं: या तो वे अपने मॉड्यूल अपडेट करते हैं (आज नोड में निर्भरताओं के समान) या हम ईआरई के कई वैश्विक संस्करणों (

इलेक्ट्रॉन का तेजी से रिलीज चक्र होता है

यह बहुत अच्छा है, इसमें कोई संदेह नहीं है। लेकिन हो सकता है कि लोग मासिक रिलीज के साथ जीवित रह सकें, इसलिए ईआरई संस्करणों की मात्रा सीमित कर दी गई है।

एक वैश्विक संस्करण बनाने के लिए स्वतंत्र महसूस करें

हाँ... ऐसा नहीं करने वाला। मेरे पास कौशल नहीं है, लेकिन अगर मेरे पास होता तो मैं होता।

मैं केवल उन सुझावों की पेशकश कर सकता हूं जो मुझे प्रासंगिक लगते हैं, और विशेषज्ञों को अपना काम करने दें: या तो वे मुझे बताएं कि मैं अपने सुझावों के साथ बेवकूफ हूं (जो बहुत अच्छी तरह से मामला हो सकता है), या वे मानते हैं कि इससे कुछ अच्छा हो सकता है . जो भी हो :)

मुझे अभी भी लगता है कि एक वैश्विक ईआरई सबसे अच्छा समाधान होगा, भले ही इसका मतलब अलग-अलग ऐप की विभिन्न जरूरतों के लिए कई ईआरई हों। लेकिन, फिर से, यह सिर्फ एक विचार है जो मेरे पास जेआरई से तुलना करने से था।

@रेनॉडपेरिस

यह दुखद समाचार है... मैं व्यक्तिगत रूप से 40एमबी फाइल के बारे में ज्यादा परवाह नहीं करता, लेकिन 120एमबी (जैसा कि मैंने सुना) हालांकि हैलो वर्ल्ड के लिए थोड़ा ज्यादा है।

120MB असम्पीडित है, यदि आप इसे संपीड़ित करते हैं तो यह लगभग 40MB है। उदाहरण के लिए, विंडोज़ इंस्टॉलेशन EXE के लिए VSCode 64-बिट लगभग 42.8 एमबी है।

व्यक्तिगत रूप से, एक उपयोगकर्ता के रूप में, मेरे पास वैश्विक जेआरई (या ईआरई) को प्रबंधित करने की आवश्यकता के बिना हमेशा स्वयं निहित एप्लिकेशन होगा, भले ही मुझे 10 एमबी के बजाय 200 एमबी डाउनलोड करना पड़े।

यह सिर्फ 120mb नहीं है, मैंने एक साधारण वेब एप्लिकेशन बनाया जो वेब सर्वर पर ~ 1mb था लेकिन OS X पर एक इलेक्ट्रॉन ऐप के रूप में ~ 300mb था

साथ ही, यह तब और महत्वपूर्ण हो जाता है जब एक ही मशीन पर कई इलेक्ट्रॉन ऐप चल रहे हों।
तब यह 10 गुना, 20 गुना बड़ा होगा।
इलेक्ट्रॉन के साथ निर्मित कंप्यूटर पर अब कई मानक ऐप हैं जैसे स्लैक, वीएससीओडी इत्यादि। और नोडओएस जैसी बड़ी परियोजनाएं भी हैं।

Node.js में>500k मॉड्यूल हैं। यदि इलेक्ट्रॉन बेहतर और तेज और अधिक लोकप्रिय और छोटा हो जाता है, तो डेस्कटॉप पर कई और ऐप्स होंगे, जिनमें जीबी की अनावश्यक इलेक्ट्रॉन फाइलें होंगी।

इलेक्ट्रॉन सिर्फ सबसे अच्छा ढांचा नहीं है।

मैं इसके बजाय फ्लैश आदि जैसे क्रोम ढांचे के अनावश्यक हिस्सों को विभाजित करने पर ध्यान दूंगा।

@yasinaydin

वेब सर्वर पर 1mb लेकिन OS X पर इलेक्ट्रॉन ऐप के रूप में ~300mb

वितरण से पहले आपको अपने आवेदन को साफ करना होगा (संकेत: अपने नोड_मॉड्यूल की जांच करें)। उदाहरण के लिए, विंडोज़ पर वीएससीओडी इंस्टॉलेशन के बाद 228 एमबी है (डाउनलोड करने योग्य इंस्टॉलेशन केवल 42.8 एमबी है)।

लेकिन, इंस्टॉलेशन आकार केवल एक समस्या है, दूसरी समस्या यह है कि रैम एप्लिकेशन कितना उपयोग कर रहा है और लॉन्च का समय। मेरे अनुभव में, एक बार एप्लिकेशन लॉन्च होने के बाद एप्लिकेशन की गति कोई समस्या नहीं है।

छोटे अनुप्रयोगों के लिए इलेक्ट्रॉन एक अच्छा मेल नहीं है, लेकिन VSCode जैसे बड़े अनुप्रयोगों के लिए यह काम करता है।

दूसरी समस्या यह है कि RAM एप्लिकेशन कितना उपयोग कर रहा है और लॉन्च समय

@mvladic क्या आपको नहीं लगता कि ठीक यही दो और मुद्दे हैं जिन्हें एक ERE ठीक करेगा? ऐप्स और सभी के बीच पहले से लोड और साझा किया जा रहा है।

ठीक है, हो सकता है कि लोगों के पास एक ही समय में 10 इलेक्ट्रॉन ऐप न चल रहे हों... लेकिन शायद वे ऐसा करेंगे! जितना संभव हो सके निर्भरताओं को फैक्टर करना महत्वपूर्ण है।

मुझे लगता है कि इलेक्ट्रॉन को पहले पीओसी के रूप में लॉन्च किया गया था, और फिर देवों को खुश करने के लिए बहुत बार रिलीज की आवश्यकता थी। लेकिन हो सकता है कि अब जब इलेक्ट्रॉन अधिक परिपक्व हो गया है, तो सर्वोत्तम संभव {लोड समय, रैम उपयोग, डाउनलोड आकार} सुनिश्चित करने के लिए कुछ उपाय करने होंगे।

दोबारा, मैं केवल उन मुद्दों के समाधान का प्रस्ताव दे रहा हूं (बेवकूफ, मुझे नहीं पता) कि इलेक्ट्रॉन उपयोगकर्ता शुरुआत से ही चिंतित हैं। लेकिन जहां तक ​​मेरा सवाल है, मुझे अपनी छोटी-छोटी जरूरतों के लिए इलेक्ट्रॉन की वर्तमान स्थिति से कोई फर्क नहीं पड़ता। इलेक्ट्रॉन महान है, मैं इसे और भी बेहतर बनाने के तरीकों के बारे में सोच रहा हूं।

इलेक्ट्रॉन सिर्फ सबसे अच्छा ढांचा नहीं है।

@ fab1an , निर्भर करता है कि लोगों को क्या चाहिए। मेरे लिए, यह पूरी तरह से मेरी ज़रूरतों के अनुकूल है, क्योंकि मुझे यकीन नहीं है कि पीडब्लूए पर्याप्त परिपक्व हैं। लेकिन फिर शायद अन्य लोगों के लिए क्यूटी बेहतर अनुकूल होगा, आप इसके बारे में सही हैं।

एक रनटाइम पहले प्रस्तावित और चर्चा की गई है और अभी भी एक खुली चर्चा है । लेकिन यह उन चीजों में से एक है जिसे करने से कहना आसान है। जैसा कि आप देख सकते हैं कि हर कोई एक ही पृष्ठ पर नहीं पहुंच पाया है या यह पता लगाने में सक्षम नहीं है कि इसे जमीन से कैसे ठीक से निकाला जाए जहां यह उत्पादन में भरोसेमंद रूप से काम करेगा। अगर आपको लगता है कि आप चर्चा में योगदान दे सकते हैं या इसे शुरू करने में मदद कर सकते हैं, तो मुझे नहीं लगता कि किसी को भी अतिरिक्त मदद की परवाह होगी।

मेरे सहित बहुत सारे देव 40 मेगा डाउनलोड करने और छोटे डेल्टा अपडेट का उपयोग करके इसे अपडेट करने से बहुत खुश हैं। लोगों को आज 40 मेगा प्रोग्राम डाउनलोड करने में कोई समस्या नहीं है। और यहां तक ​​कि छोटे प्रोग्राम जो कि कुछ मेग फ़ाइल हैं, 40 मेग्स - 2 गिग्स को डाउनलोड और इंस्टॉल कर सकते हैं और किसी को भी कोई समस्या नहीं है। इसके साथ। भले ही रनटाइम विकल्प उपलब्ध हो, संभावना है कि उपयोगकर्ता के पास यह नहीं होगा और वैसे भी आपकी परियोजना को चलाने के लिए 40+ मेगा डाउनलोड करना होगा।

यदि यह चेतावनी आपकी चाय का प्याला नहीं है तो जरूरत पड़ने पर दूसरे विकल्प पर गौर करें। मेरा मतलब यह नहीं है कि स्पष्ट रूप से, कभी-कभी आपको उन लक्ष्यों और शर्तों को पूरा करने के लिए प्रौद्योगिकियों को समाप्त करना पड़ता है जिन्हें आप पूरा करना चाहते हैं। लेकिन यह इलेक्ट्रॉन को खराब तकनीक नहीं बनाता है या इसे कई अन्य लोगों के लिए अनुपयोगी नहीं बनाता है। इलेक्ट्रॉन हर समाधान को हल करने के लिए नहीं है। और यह वास्तव में कभी नहीं होगा।

@baconbrad अगर आपकी टिप्पणी मुझे लक्षित कर रही है, तो मुझे समझ में नहीं आता क्यों, जैसा कि मैंने कई बार स्पष्ट रूप से कहा था कि मैं बहुत खुश था, और यह कि इलेक्ट्रॉन मेरी (विशिष्ट) जरूरतों के लिए उपयुक्त तकनीक थी।

मैंने केवल इतना कहा कि मैंने पैकेज के आकार के बारे में हर जगह कई लोगों को शिकायत करते देखा और मैं उस समस्या का (फिर से भोला) समाधान पेश कर रहा था, जो मुझे आदर्श लग रहा था। लेकिन मैं बहुत गलत हो सकता हूं और किसी भी मामले में यह मुझे मेरी भविष्य की जरूरतों के लिए इलेक्ट्रॉन का उपयोग करने से बिल्कुल नहीं रोकेगा :)

भले ही रनटाइम विकल्प उपलब्ध हो, संभावना है कि उपयोगकर्ता के पास यह नहीं होगा और वैसे भी आपकी परियोजना को चलाने के लिए 40+ मेगा डाउनलोड करना होगा।

हाँ, लेकिन मैं बहुत से लोगों को जानता हूँ, यहाँ तक कि मध्य पेरिस में भी, जिनके पास केवल 5Mbps इंटरनेट कनेक्शन है, और उन लोगों के लिए, प्रत्येक ऐप के लिए 40MB (यानी 320Mb) की बचत करने का अर्थ है हर बार ऐप अपडेट होने पर कुछ मिनट बचाना (नहीं भूल जाते हैं कि 40MB प्रत्येक अद्यतन के लिए होगा, न कि केवल पहली स्थापना के लिए), यह देखते हुए कि उनके इंटरनेट कनेक्शन का उपयोग नहीं किया गया है।

यह रैम की बचत को भी ध्यान में नहीं रख रहा है, खासकर नोटबुक के लिए। फिर, मैं व्यक्तिगत रूप से चिंतित महसूस नहीं करता क्योंकि मेरे पास 32GB रैम के साथ एक अपेक्षाकृत अच्छी मशीन है, लेकिन मैं यहां अपने बारे में नहीं सोच रहा हूं, बल्कि शिकायत करने वाले लोगों के बारे में सोच रहा हूं, और उनके लिए एक समाधान खोजने की उम्मीद कर रहा हूं।

अंतिम लेकिन कम से कम, आपके पास एक अच्छा कनेक्शन हो सकता है, और इसलिए मैं (एक बिजली तेज अगर आप कृपया! :)), और हम दोनों में 16 या 32 या 64GB RAM हो सकती है, इसलिए आप (स्वयं) डॉन ' प्रत्येक अपडेट के लिए 40 एमबी डाउनलोड करने में कोई दिक्कत नहीं है, लेकिन आपके उपयोगकर्ताओं के बारे में क्या है (यह देखते हुए कि आप लोगों को अपना ऐप वितरित करते हैं)?

वैसे भी, मैं इसके बारे में नहीं लड़ूंगा, मैं केवल मदद करना चाह रहा था, और जैसा कि मैंने कहा कि मैं बहुत खुश हूं, और मेरे पास इसमें शामिल होने के लिए बहुत सी चीजें हैं।

अगर कुछ लोग सोचते हैं कि मैं समाधान के बारे में सोचने में उनकी मदद कर सकता हूं, तो मुझे हाथ उधार देने में खुशी होगी, लेकिन अन्यथा मैं काम पर वापस जाऊंगा :)

चीयर्स,

एक चीज जो मैंने देखी, जब अधिक निर्भरता को देव-निर्भरता पर ले जाया गया, तो इसे बनाने के लिए जितना अधिक समय चाहिए।

````
✔ मुख्य प्रक्रिया का निर्माण

• बिल्डिंग रेंडरर प्रक्रिया
  ````

इसने "बिल्डिंग रेंडरर प्रक्रिया" पर बहुत अधिक समय बिताया, और एनिमेटेड आइकन बंद हो जाता है जैसे यह क्रैश हो जाता है लेकिन ऐसा नहीं हुआ। फिर यह रेंडरर रिपोर्ट से 203778ms दिखाता है।

निर्भरता को वापस निर्भरता में ले जाना, निर्माण समय फिर से सामान्य है लेकिन ऐप बड़ा है।

अगर मुझे निर्माण के दौरान कोई त्रुटि नहीं हो रही है, तो इसका मतलब है कि यह सब ठीक है, है ना?

@karimhossenbux यह मेरे लिए सामान्य है। electron-packager में एक वॉक फ़ंक्शन है जो सभी निर्भरताओं के माध्यम से यह निर्धारित करने के लिए जाता है कि उन्हें वहां होना चाहिए या नहीं। नेस्टेड के बजाय नई फ्लैट शैली निर्भरताओं के साथ अनावश्यक निर्भरताओं को निर्धारित करने में बहुत अधिक समय लगेगा। जहां तक ​​​​मुझे पता है कि अतिरिक्त निर्माण समय के आसपास जाने का कोई रास्ता नहीं है।

@baconbrad धन्यवाद! मैं electron-builder का उपयोग कर रहा हूं लेकिन मुझे लगता है कि यह वैसे ही काम करता है।

क्या कोई इलेक्ट्रॉन पैकेज बिल्डर है जिसमें केवल आपका स्रोत शामिल है और अन्य डाउनलोड करें (केवल वर्तमान ऑपरेटिंग सिस्टम उपयोगकर्ता के लिए आवश्यक है) जब उपयोगकर्ता पहली बार आपका ऐप चलाता है? यह वितरण के लिए आसान बना देगा और आपके ऐप के आकार को काफी कम कर देना चाहिए।

इलेक्ट्रॉन, कृपया "ईआरई" मार्ग पर न जाएं। हां, मुझे पता है कि आप फूले हुए हैं, लेकिन मुझे यह पसंद है कि लोग मेरे एप्लिकेशन को कैसे डाउनलोड कर सकते हैं और यह सिर्फ डिप्स स्थापित करने, रनटाइम पर्यावरण को अपडेट करने, या उस बकवास के किसी भी बकवास के बिना बहुत अच्छा चलता है जिसे मैंने सोचा था कि हम लगभग 2003 से छुटकारा पा चुके हैं .

खैर, एक बंडल डाउनलोड करना अभी भी एक विकल्प होगा। शिकायत करने के लिए कुछ नहीं
यहाँ के बारे में :)

ले वेन। 25 मई 2018 à 21:03, ल्यूक पिगेटी नोटिफिकेशन @github.com a
इक्रिट:

इलेक्ट्रॉन, कृपया "ईआरई" मार्ग पर न जाएं। हाँ, मुझे पता है कि तुम फूले हुए हो,
लेकिन मुझे पसंद है कि लोग मेरे एप्लिकेशन को कैसे डाउनलोड कर सकते हैं और यह बहुत अच्छा चलता है
डिप्स स्थापित करने के साथ, रनटाइम को अपडेट करने के साथ पेंच किए बिना
पर्यावरण, या उस बकवास में से कोई भी जो मुझे लगा कि हमने लगभग छुटकारा पा लिया है
2003.

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/electron/electron/issues/2003#issuecomment-392151709 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AApUIBjAeVZ7T4SKo8LyW6RT65XnpiKgks5t2FWfgaJpZM4FGGer
.

मैं सिर्फ Microsoft इंजीनियरों के इलेक्ट्रॉन में सुधार की प्रतीक्षा कर रहा हूं।
https://news.ycombinator.com/item?id=17229973

मैं सिर्फ Microsoft इंजीनियरों के इलेक्ट्रॉन में सुधार की प्रतीक्षा कर रहा हूं।
https://news.ycombinator.com/item?id=17229973

@zcmgyu माइक्रोसॉफ्ट ने कुछ वर्षों के लिए डेवलपर्स को इलेक्ट्रॉन पर काम करने के लिए नियोजित किया है क्योंकि उन्होंने इसे वीएस कोड के लिए उपयोग करना शुरू कर दिया है। और वे कुछ सबसे बड़े योगदानकर्ता हैं और उन्होंने इसमें काफी सुधार किया है।

यदि आपका आवेदन 100 एमबी से अधिक है,
हो सकता है कि आपके exe में आपके node_modules फ़ोल्डर का एक अच्छा हिस्सा शामिल हो।
ध्यान दें कि निर्भरता में package.json में घोषित सब कुछ अंतिम निष्पादन योग्य में वापस आयात किया जाता है।
(सत्यापित करने के लिए बहुत आसान: यह निष्पादन योग्य को विघटित करने के लिए पर्याप्त है)
इसलिए निर्भरता (इलेक्ट्रॉन-लॉग, इलेक्ट्रॉन-अपडेटर) में केवल आवश्यक कामों को परिभाषित करना याद रखें और अन्य सभी कामों को देव निर्भरता में जोड़ें।

आपका ऐप तब "केवल" 50 एमबी होगा ...

मेरा ऐप छोटा है- यहाँ रेपो है। नवीनतम प्रयोगात्मक संस्करण का वजन लगभग 700mb . है
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

मैं भी इस बारे में सोच रहा हूं। मेरे इलेक्ट्रॉन ऐप के आकार यहां दिए गए हैं:

  osx - 117.3 mb

linux32 - 60.3 एमबी
linux64 - 55.2 एमबी
जीत ia32 - 47.8 एमबी
विन x64 - 66.2 एमबी
धन्यवाद!

अद्भुत! क्या आप इस बारे में साझा कर सकते हैं कि इलेक्ट्रॉन ऐप को इतने छोटे आकार में कैसे कम किया जाए।