Less.js: ES6 और रोलअप

नहीं। मैं थोड़ी देर से उसी तर्ज पर सोच रहा था। टाइपस्क्रिप्ट का उपयोग करने के बारे में क्या? यह कोड संकेत/वास्तविक वस्तु जोड़ने के लिए विकास/योगदान को आसान बना सकता है। हालांकि मुझे नहीं पता कि क्या यह ज्ञान का बोझ/बाधा डाल देगा।

मैं भी उसी तर्ज पर सोच रहा था कि हमें पार्सिंग/एएसटी के लिए ईएस 6 संग्रह का उपयोग करने पर विचार करना चाहिए और फिर ईएस 5 के लिए पॉलीफिल का उपयोग करना चाहिए जैसे https://github.com/Benvie/harmony-collections। ES6 वातावरण में (जो Node.js अब है, जैसा कि नवीनतम ब्राउज़र हैं) जो सैद्धांतिक रूप से कम मेमोरी ओवरहेड और तेज़ AST निर्माण के कारण पार्सिंग / मूल्यांकन को गति देना चाहिए।

टाइपस्क्रिप्ट का उपयोग करने के बारे में क्या? यह कोड संकेत/वास्तविक वस्तु जोड़ने के लिए विकास/योगदान को आसान बना सकता है। हालांकि मुझे नहीं पता कि क्या यह ज्ञान का बोझ/बाधा डाल देगा।

हम विचार कर सकते हैं कि ES6 के बाद - es6 टाइपस्क्रिप्ट को बाहर नहीं करता है क्योंकि टाइपस्क्रिप्ट एक es6 ट्रांसपिलर भी है .. इसके बाद यह एक अतिरिक्त कदम होगा।

मैं व्यक्तिगत रूप से टाइपस्क्रिप्ट की अनुशंसा नहीं करता जब तक कि महत्वपूर्ण अतिरिक्त काम या कम में रिफैक्टरिंग न हो। आईएमओ टाइपस्क्रिप्ट

• + नए लोगों के लिए विकास बनाता है जो टाइपस्क्रिप्ट को आसान जानते हैं
• + रखरखाव बढ़ाता है
• 
  
  • लोगों को टाइपस्क्रिप्ट की न्यूनतम मात्रा जानने या सीखने की आवश्यकता होती है
  
  
• 
  
  • कोड लिखने में अधिक समय लगता है ताकि वह टाइप हो जाए
  
  

मैं भी उसी तर्ज पर सोच रहा था कि हमें पार्सिंग/एएसटी के लिए ईएस 6 संग्रह का उपयोग करने पर विचार करना चाहिए और फिर ईएस 5 के लिए पॉलीफिल का उपयोग करना चाहिए जैसे https://github.com/Benvie/harmony-collections। ES6 वातावरण में (जो Node.js अब है, जैसा कि नवीनतम ब्राउज़र हैं) जो सैद्धांतिक रूप से कम मेमोरी ओवरहेड और तेज़ AST निर्माण के कारण पार्सिंग / मूल्यांकन को गति देना चाहिए।

मैं उस पॉलीफिल का उपयोग नहीं करता, परियोजना मृत दिखती है (शायद इसलिए भी कि नाम सद्भाव मर चुका है)।

इसके अलावा, दुर्भाग्य से मुझे यकीन नहीं होगा कि ES6 मूल समकक्ष तेज हैं - https://jsperf.com/property-access-object-array-map-weakmap/6। यह दुख की बात है कि उदाहरण के लिए वादा पॉलीफिल मूल कार्यान्वयन से तेज है :(

:+1:

सभी अच्छे अंक। ES6 / Babel पर मानकीकरण अक्सर चीजों को न केवल लिखना, बल्कि पढ़ना आसान बनाता है, खासकर जब प्रोटोटाइपिक इनहेरिटेंस करते समय।

जहां तक ​​​​जेएसपीआरएफ परीक्षण है, यह वास्तव में एक उचित उदाहरण नहीं है। मुझे उम्मीद है कि वीकमैप उस विशिष्ट परीक्षण के लिए धीमा प्रदर्शन करेगा। सिद्धांत रूप में, लेस के लिए विभिन्न ऑब्जेक्ट आकृतियों और प्रकारों का एक गुच्छा बनाना और फिर उनका मूल्यांकन करना बेहतर हो सकता है। हालांकि यकीन नहीं है। मुझे कुछ अच्छी लाइब्रेरी मिलीं जिन्हें मैं अंततः परीक्षण करना चाहता हूं (और उम्मीद है कि जोड़ना) जहां हम किसी भी "बेंचमार्किंग हुक" को lib में डालने के बिना, दानेदार बेंचमार्किंग करने के लिए अलग-अलग कार्यों में लगा सकते हैं। मैं कुछ सेट अप करने की उम्मीद कर रहा हूं (जब मेरे पास समय होगा, कौन जानता है कि वह कब होगा) ताकि आप कम.जेएस के भीतर कार्यों पर एक प्रकार का जेएसपीआरएफ परीक्षण कर सकें, लेकिन स्थानीय विकास/शाखा कम बनाम में बदल जाती है। वर्तमान रिलीज़, और कुछ प्रकार की परीक्षण .less फ़ाइलों का उपयोग करना। जैसा कि मैंने पहले उल्लेख किया है, हमें यह अनुमान लगाने की आवश्यकता नहीं है कि हमारे विशेष उपयोग के मामले में कौन सा तेज़ है। हम सैद्धांतिक रूप से कुछ फ़ंक्शन स्तर बनाम कच्ची वस्तुओं पर वीक मैप में उप कर सकते हैं, उस स्थान पर बेंचमार्क चला सकते हैं, और परिणाम के आधार पर निर्णय ले सकते हैं।

@lukeapage ने लिखा:
आईएमओ टाइपस्क्रिप्ट

• + नए लोगों के लिए विकास बनाता है जो टाइपस्क्रिप्ट को आसान जानते हैं
• + रखरखाव बढ़ाता है
• 
  
  • लोगों को टाइपस्क्रिप्ट की न्यूनतम मात्रा जानने या सीखने की आवश्यकता होती है
  
  
• 
  
  • कोड लिखने में अधिक समय लगता है ताकि वह टाइप हो जाए
  
  

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

टाइपस्क्रिप्ट में जाने से शायद ES6, इम्हो में जाने से अधिक योगदान होगा।

टाइप मोड से आपका मतलब मना है कोई?

मैंने कोशिश की कि एक छोटी परियोजना पर और मेरे पास हर जगह टिप्पणियां थीं .. यह समाप्त होता है
बहुत सारे कोड के साथ क्योंकि ट्रांसपिलर सुपर चालाक नहीं है।

कितने चर चर प्रकार उत्परिवर्तित हैं, मुझे यकीन नहीं है। इसलिए..
आश्वस्त नहीं हैं कि प्रदर्शन लाभ ध्यान देने योग्य होगा।

@rjgotten मैंने टाइपस्क्रिप्ट का उपयोग नहीं किया है, लेकिन वे अच्छे बिंदु हैं। यदि आप टाइपस्क्रिप्ट के लिए एक इंटेलिजेंस/स्वत: पूर्ण वातावरण का उपयोग कर रहे हैं, तो यह वास्तव में नए योगदानकर्ताओं की मदद कर सकता है क्योंकि जब आप परिवर्तन करते हैं तो यह प्रकार/ऑब्जेक्ट आकार को पूरा करेगा। उचित रूप से डिज़ाइन किया गया, यह कोड परिवर्तन में योगदान करने वाले किसी व्यक्ति के लिए एक प्रकार का स्व-दस्तावेजीकरण / परिचित / त्रुटि-रोकथाम उपकरण के रूप में काम कर सकता है। लेकिन कुंजी शायद टाइपस्क्रिप्ट डिज़ाइन में है।

कुल मिलाकर, क्या कोई प्रदर्शन लाभ होगा? यह निर्धारित करना कठिन है। वह कैनवास से ज्यादा कलाकार है।

भले ही मैं अपनी खुद की परियोजनाओं के लिए टाइपस्क्रिप्ट का उपयोग करने का लक्ष्य रख रहा हूं, मैं शायद @lukeapage से सहमत होने के लिए थोड़ा अधिक इच्छुक हूं, मुख्यतः क्योंकि, जब तक हम में से कोई भी टाइपस्क्रिप्ट विशेषज्ञ नहीं है, मुझे यकीन नहीं है कि हम प्रभावी उपयोग कर सकते हैं इसकी शुरुआत में।

साथ ही, ES6 में जाना भविष्य में टाइपस्क्रिप्ट के उपयोग को नहीं रोकता है। Microsoft / Google का लक्ष्य टाइपस्क्रिप्ट 2.0 को ES6 सुपरसेट बनाना है, इसलिए हम हमेशा ES6 / Babel से शुरू कर सकते हैं, और बाद में उचित प्रकार जोड़ सकते हैं और टाइपस्क्रिप्ट ट्रांसपिलर पर स्विच कर सकते हैं। मेरा संदेह यह है कि टाइपस्क्रिप्ट ट्रांसपिल्ड भाषाओं को "जीतने" जा रहा है, सिर्फ इसलिए कि संकलन-समय/स्वत: पूर्ण लाभ गैर-टाइप की गई जावास्क्रिप्ट पर बहुत अधिक हैं। तो... मुझे लगता है कि इसका मतलब है कि मुझे लगता है कि टाइपस्क्रिप्ट का उपयोग करना शायद अपरिहार्य है, लेकिन इसका मतलब यह नहीं है कि हमें इसका तुरंत उपयोग करना होगा।

मैं किसी बिंदु पर कम के लिए एक अलग वास्तुशिल्प दृष्टिकोण पर चर्चा करना चाहता हूं, लेकिन यह इस पर एक स्पर्शपूर्ण चर्चा है।

टाइप मोड से आपका मतलब मना है कोई?

नहीं, सामान्य रूप से टाइप किए गए चर का उपयोग करना। आप किसी भी सामान्य रूप से किसी के उपयोग को मना कर सकते हैं, लेकिन यह (कम से कम व्यावहारिक रूप से) एक बुरा विचार है क्योंकि यह टाइपिंग सिस्टम को संतुष्ट करने के लिए बहुत सारे कोड ब्लोट का कारण बनता है।

हालाँकि, किसी फ़ंक्शन पर टाइप किए गए मापदंडों के उपयोग का मतलब यह है कि कॉल करने वाले (टाइपस्क्रिप्ट में लिखे गए कम से कम कॉल करने वाले) _must_ दिए गए प्रकार का सम्मान करते हैं। इसका मतलब है कि टाइप किए गए कार्यों का उपयोग कम कंपाइलर के आंतरिक कामकाज पर टाइप स्थिरता की रक्षा के लिए किया जा सकता है जहां उपयुक्त हो और गारंटी हो कि विशेष रूप से महत्वपूर्ण कार्यों को अच्छी तरह से अनुकूलित किया जाएगा। (मत भूलना; जेएस इंजन आमतौर पर फ़ंक्शन स्तर पर अनुकूलित होते हैं ...)

काम शुरू - https://github.com/less/less.js/tree/rollup

बहुत बढ़िया काम। चर्चा के लिए जर्मेन, मैं कोड देख रहा था और जल्दी से आया:

if (typeof index === 'number') {   

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

दूसरी ओर, यह हो सकता है कि यह एक अलग और दुर्लभ उदाहरण है; यह कुछ ऐसा है जो मुझे मिला जो प्रासंगिक लग रहा था।

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

मैंने अभी तक टाइपस्क्रिप्ट का उपयोग नहीं किया है, इसलिए मुझे नहीं पता कि उपकरण इतने परिपक्व हैं कि इसे इसके लायक बना सकें। जावास्क्रिप्ट का लाभ यह है कि हर कोई इसे जानता है, टाइपस्क्रिप्ट कम ज्ञात है।

कुल मिलाकर, मुझे लगता है कि अगर हम किसी प्रकार की बड़ी रिफैक्टरिंग या बड़ी नई सुविधाओं की योजना बनाते हैं तो टाइपस्क्रिप्ट में जाने का कोई मतलब होगा, लेकिन यह बहुत अधिक काम हो सकता है जबकि हम केवल छोटी बग को ठीक कर रहे हैं।

मुझे लगता है कि अगर हम किसी प्रकार की बड़ी रिफैक्टरिंग या बड़ी नई सुविधाओं की योजना बनाते हैं तो टाइपस्क्रिप्ट में जाने का कोई मतलब होगा, लेकिन यह बहुत अधिक काम हो सकता है जबकि हम केवल छोटी बग को ठीक कर रहे हैं।

यह मामला हो सकता है, और वास्तव में, व्यावहारिक होने के लिए, @lukeapage ने पहले ही काम कर लिया है, इसलिए मैं यह कहना चाहता हूं कि उसे इस समय अंतिम कॉल करना चाहिए। :-)

अरे, इसके बारे में: क्या हमें लोगों को यह बताने के लिए कुछ करना चाहिए कि कोडबेस बदल रहा है? मुझे लगता है कि अन्यथा आपके पास विलय विवाद होंगे।

नहीं, बहुत अधिक संघर्ष नहीं होने चाहिए। पहला कदम सिर्फ es6 मॉड्यूल है - नहीं
किसी भी फाइल को मूव करना, फिर हम पारदर्शी रूप से बेबेल या टाइपस्क्रिप्ट जोड़ सकते हैं।

हेलो दोस्तों, अब कैसा चल रहा है?

मैं इस पर काम कर सकता हूं। @ मैथ्यू-डीन क्या आप पुल अनुरोध स्वीकार करेंगे?

@alexlur निश्चित रूप से! मेरी एकमात्र चिंता 3.x शाखा के लिए रिफैक्टरिंग और विलय विवाद नहीं हो रही है। तो वहां से कांटा/शाखा लेना बेहतर है। साथ ही, चूंकि यह अंक लिखा गया था, अब src/ और dist/ का उपयोग करने की एक सुस्थापित परंपरा है। हालांकि, lib/ को कभी-कभी src/ के रूप में उपयोग किया जाता है, इसलिए शायद नाम बदलने की कोई आवश्यकता नहीं है।

ग्रंटफाइल का एक छोटा सा पुन: लेखन भी होगा ताकि परीक्षण बिल्ड का उपयोग कर रहे हों न कि lib/ । (ब्राउज़र परीक्षण क्या करता है test/ में एक बिल्ड करता है और dist/ नहीं। dist/ फ़ोल्डर नई रिलीज के लिए एक विशेष ग्रंट कार्य है। परीक्षण करते समय, इसे बनाना चाहिए test/ ) ऐसा करने के बाद, जब तक परीक्षण पास हो जाते हैं, आपको अच्छा होना चाहिए।

@ मैथ्यू-डीन नमस्ते। मैं रिफैक्टरिंग के साथ कर रहा हूं लेकिन मुझे नहीं पता कि नई निर्मित फाइलों पर परीक्षण चलाने के लिए ग्रंटफाइल को कैसे कॉन्फ़िगर किया जाए।

हो सकता है कि मैं आपके परिवर्तनों को एक अलग शाखा में विलय कर दूं और परीक्षणों को एकीकृत करने के बारे में देखूं। मैं जल्दी से आपके परिवर्तनों को देख रहा था। अगर मैं गलत हूं तो मुझे सुधारें, लेकिन क्या at-rule गलत तरीके से assignment नोड है? या जीथब सिर्फ गड़बड़ कर रहा था कि वह कैसे दिखा रहा था?

अच्छी पकड़, मैंने गलत फाइल का इस्तेमाल किया।

क्या ब्राउज़र / Node.js का कोई न्यूनतम संस्करण है जिसे कम.js को समर्थन देना चाहिए? Node.js के पास Promise (0.12 के बाद से) के लिए काफी अच्छा समर्थन है, जबकि ब्राउज़र का उपयोग आम तौर पर उन डेवलपर्स के लिए होता है जो पहले से ही नवीनतम ब्राउज़र संस्करण चलाते हैं।

संपादित करें:

Less.js सभी आधुनिक ब्राउज़रों का समर्थन करता है (Chrome, Firefox, Safari, IE11+ और Edge के हाल के संस्करण)

केवल Internet Explorer 11 में Promise अंतर्निहित नहीं है।

@alexlur
कम के इन-ब्राउज़र संस्करण के लिए, मैं एक less.Promise संपत्ति बनाने और इसे डिफ़ॉल्ट रूप से window.Promise पर सेट करने का सुझाव दूंगा। और फिर less.Promise के माध्यम से Promise क्लास का कम उपभोग करें।

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

@rjgotten @alexlur Less.js में पहले से ही Promise पॉलीफ़िल पहले से ही सेट हैं। वहां कोई अतिरिक्त काम करने की जरूरत नहीं है। अधिकांश कोड इस पैटर्न का उपयोग करते हैं:

https://github.com/less/less.js/blob/55380d49e96a6ed561cac4d13a774830aa3c17a3/lib/less/import-manager.js#L5

नोड पक्ष पर, यह समस्या अभी भी खुली है: https://github.com/less/less.js/issues/3121

हालांकि, बिना किसी प्रतिक्रिया के, और काफी मध्यम मात्रा में योगदानकर्ताओं के साथ, मैं सिर्फ यह कहना चाहता हूं कि Node 4+ अभी जाने का रास्ता है। हमें इसे दर्शाने के लिए डॉक्स/परीक्षणों को अपडेट करना चाहिए।

@ मैथ्यू-डीन इसे एक अलग शाखा में विलय करने के लिए तैयार होना चाहिए।

@alexlur धन्यवाद! मैं जल्द ही एक नज़र डालने की कोशिश करूँगा। संभवत: अगले सप्ताह होगा (जब तक कि किसी और के पास इसकी जांच करने की सुस्ती न हो)।

इस समस्या को स्वचालित रूप से पुराने के रूप में चिह्नित कर दिया गया है क्योंकि इसमें हाल की गतिविधि नहीं है। आगे कोई गतिविधि नहीं होने पर इसे बंद कर दिया जाएगा। आपके योगदानों के लिए धन्यवाद।

मैंने टाइपस्क्रिप्ट के लिए एक कांटा बनाया।

मैंने टाइपस्क्रिप्ट के लिए एक कांटा बनाया।

@glixlur वाह, और सभी परीक्षण पास हो गए? और dist/ में एक समान कम.जेएस बनाता है?

@ मैथ्यू-डीन मैं अभी भी इस पर काम कर रहा हूं, लेकिन ब्राउज़र के लिए मेरे निर्माण में अब तक दैनिक ड्राइवर के रूप में कोई समस्या नहीं आई है। तकनीकी रूप से रोलअप का उपयोग करने से मेरे कांटे को प्रदर्शन में बढ़त मिलती है लेकिन मेरे पास इसका बैकअप लेने के लिए डेटा नहीं है।

@less/core यह देखने के लिए जांच की जानी चाहिए कि क्या हम इसे एक बार के रूपांतरण के लिए स्वचालित कर सकते हैं - https://github.com/lebab/lebab

@ मैथ्यू-डीन एक बार काम पूरा हो जाने के बाद मैं आपको एक पुल अनुरोध भेजूंगा।

@glixlur ओह! ठीक है, अपने पिछले जनसंपर्क में, आपने कहा था कि आपके पास इसके लिए समय नहीं है। यदि आप अभी भी इस पर काम कर रहे हैं,

@ मैथ्यू-डीन मैं खुद को केवल ES6 में परिवर्तित करने के लिए सीमित कर दूंगा और बाद में टाइपस्क्रिप्ट भाग को छोड़ दूंगा।

@glixlur मुझे लगता है कि ES6 शायद सबसे "समुदाय के अनुकूल" पहला कदम है जो आगे बढ़ रहा है, इसलिए यह सही है। मुझे यकीन नहीं है कि हर कोई टाइपस्क्रिप्ट के साथ बोर्ड पर है, लेकिन निश्चित रूप से एक ES6 प्रवाह बहुत अच्छा होगा।

@ मैथ्यू-डीन मुझे लगता है कि सबसे कम समर्थित प्लेटफॉर्म नोड 6 और आईई 11 हैं?

@glixlur Appveyor वर्तमान में नोड 4 का परीक्षण करने के लिए स्थापित है। क्या इससे चीजें और कठिन हो जाएंगी? आदर्श रूप से, यह नोड/ब्राउज़र के वितरण के लिए src/ फ़ोल्डर को lib/ (और ब्राउज़र के लिए dist/ ) फ़ोल्डर (फ़ोल्डर) में बदल देता है। तो मुझे लगता है कि बैबेल ES5 को ट्रांसपिलिंग का अधिकांश काम कर रहा है।

हो गया , लेकिन परीक्षण काम करने की जरूरत है। PhantomJS पदावनत है और ES5 के बाद किसी भी चीज़ के लिए उसका कोई समर्थन नहीं है।

@glixlur नाइस! पुन: PhantomJS, इसे वास्तव में Chromy जैसी किसी चीज़ से बदलने की आवश्यकता है। देखें: https://github.com/less/less.js/issues/3240

@glixlur इसके अलावा, यह क्रोमी/हेडलेस क्रोम से संबंधित है: https://github.com/less/less.js/issues/3262

@glixlur PhantomJS के संबंध में - वे परीक्षण बंडल किए गए ब्राउज़र संस्करण के विरुद्ध चल रहे हैं, जिन्हें आप संभवतः ES5 में ट्रांसप्लिंग कर रहे होंगे, सही? PhantomJS ES5 आउटपुट बंडल के साथ काम क्यों नहीं करेगा?

@ मैथ्यू-डीन हां, लेकिन एक बग है जहां Symbol उपयोग बैबेल-ट्रांसपिल्ड फ़ाइल के साथ फैंटमजेएस चलाते समय किया जाता है।

@glixlur आपको पारदर्शी आउटपुट में babel-polyfill की आवश्यकता है। यह एक अच्छा संकेतक है कि यह अभी तक सही ढंग से ट्रांसपिलिंग नहीं हो रहा है। इस तरह के मुद्दे देखें: https://github.com/babel/babel-preset-env/issues/203

@glixlur https://babeljs.io/docs/en/babel-polyfill/

@ मैथ्यू-डीन babel-polyfill आउटपुट फ़ाइल में 87.3KB छोटा किया गया जोड़ता है। आप शायद ऐसा नहीं चाहते।

@glixlur
ऐसे और भी कारण हैं जिनकी वजह से आप babel-polyfill नहीं चाहते हैं। अर्थात् तथ्य यह है कि यह window पर पॉलीफ़िल प्रकाशित करके और Array जैसे मूल प्रकारों के प्रोटोटाइप को संशोधित करके वैश्विक नामस्थान को प्रभावित करता है।

इसके बजाय babel-runtime और babel-plugin-transform-runtime पैकेज देखें।

साथ ही, iirc Babel टीम transform-runtime द्वारा बंडल किए गए पॉलीफ़िल को उसी तर्ज पर सीमित करने पर काम कर रही है जैसे babel-env प्रीसेट भाषा परिवर्तन को सीमित करता है। लेकिन इस पर उनका काम अभी पूरा नहीं हुआ है और आम तौर पर उपलब्ध है। एक बैबेल 7 चीज़ को समाप्त कर देगा, जो अभी भी बीटा में है, इसलिए सीधे उपयोगी नहीं है। लेकिन निश्चित रूप से भविष्य के लिए वांछनीय है।

@glixlur @rjgotten आह। मुझे यह स्पष्ट करना चाहिए था कि मुझे नहीं पता कि किस समाधान का पुन: उपयोग करना है: बेबेल। सिर्फ इसलिए कि Symbol अपरिभाषित है क्योंकि यह पॉलीफिल्ड नहीं है (टनीफिल्ड?), जो कि IE11 में भी होगा। तो शायद यह पॉलीफ़िल नहीं है, लेकिन मेरा मानना ​​है कि सही बैबेल सेटिंग्स के साथ, यह आपको एक दायरे में Symbol परिभाषा देनी चाहिए। तो शायद यह न्यूनतम ब्राउज़र संस्करण है जो कि मुद्दा है?

सही बैबेल सेटिंग्स के साथ, यह आपको एक विस्तृत Symbol परिभाषा देनी चाहिए

यह वास्तव में होगा।
उन सेटिंग्स की राशि transform-runtime प्लगइन का उपयोग करने और babel-polyfill पर निर्भर होने के बजाय Symbol जैसे नए बिल्ट-इन के लिए उपनामों को इंजेक्ट करने की क्षमता है ।

क्या फैंटमज को बहिष्कृत किया जाना चाहिए?

इसे मरा हुआ मानते हुए?
शायद हां।

@glixlur देखें: https://github.com/less/less.js/issues/3240

रूपांतरण हो गया और विलय हो गया! देखें: https://github.com/less/less-meta/issues/32

वेलप, इस हफ्ते मैंने सीखा कि जावास्क्रिप्ट में Class फ़ंक्शन प्रोटोटाइप के लिए सिंटैक्टिक चीनी नहीं है, जिसके कारण यह समस्या हुई: https://github.com/less/less.js/issues/3414

विडंबना यह है कि, मैं एक ही चीज़ के साथ एक और बिट कोड के साथ भाग गया, जो कम से संबंधित नहीं है, 2 सप्ताह पहले की तरह कुछ और मुझे स्पष्ट रूप से उस विचार को याद है जो मुझे मार रहा था:

जी, मुझे आश्चर्य है कि अगर कम के लिए ES6 रूपांतरण इस प्रकार की समस्या का कारण होगा।

अच्छा: प्रश्न का उत्तर दिया, मुझे लगता है?

मैं _so_ उन उपयोगकर्ताओं के तूफान से ईर्ष्या नहीं करता, जिन्होंने आपके काम पर असंतोष व्यक्त किया, @ मैथ्यू-डीन। उस स्थिति को संभालने के लिए आपको मेरी सहानुभूति है। :मुस्कुराओ:
सौभाग्य से, ऐसा लगता है कि कोई भी सर्वनाश नहीं हुआ और इसे व्यवस्थित रूप से संभाला गया।

@rjgotten lol मेरा मतलब है, आप ऐसा कुछ कैसे अनुमान लगा सकते हैं? सबसे सुरक्षित बात यह होगी कि बिल्कुल भी परिवर्तित न किया जाए, या कक्षाओं का कभी भी उपयोग न किया जाए, लेकिन यह कोडबेस को कम वर्बोज़ बनाता है (अच्छी तरह से, या संभावित रूप से, आगे की सफाई के लिए बहुत सारे अवसर हैं)। तकनीकी रूप से, (ऐतिहासिक) less-loader कम के साथ एकीकरण एपीआई का गलत उपयोग कर रहा था (एपीआई के एक गैर-दस्तावेज/असमर्थित उपयोग का उपयोग करके), इसलिए यह उनकी ओर से एक गलती थी, लेकिन मुझे लोगों के निराश होने से सहानुभूति है। एक गैर-प्रमुख बिंदु रिलीज जो बिल्ड विफलता का कारण बनती है।

जैसे, अगर कोई आपकी लाइब्रेरी के प्रोटोटाइप को हैक कर लेता है, तो आप उसके लिए रक्षात्मक तरीके से कोड कैसे करते हैं ??

‍

@rjgotten

तकनीकी रूप से, मैंने रूपांतरण के बाद दो बीटा संस्करण जारी किए, लेकिन ... किसी के पास उनकी पाइपलाइन में कम बीटा नहीं है। तो 800,000 रेपो का परीक्षण करने का कोई तरीका नहीं है जो कम के साथ एकीकृत होता है और उनके परीक्षण चलाता है। एनपीएम निर्भरताओं के साथ, आपको वास्तव में इसे वहां रखना होगा और देखें कि क्या टूटता है।

एक चीज जो हम भविष्य में कर सकते हैं, वह है परीक्षणों में कुछ बड़े कम आश्रितों को जोड़ना, यदि हम यह पता लगा सकें कि वे क्या हैं?

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

हां। यह एक पेचीदा था।

मुझे लगता है कि आप .next टैग या कुछ पर कुछ डालने की कोशिश कर सकते थे और लोगों को इसके साथ अपनी बिल्ड पाइपलाइनों का परीक्षण करने के लिए जागरूक कर सकते थे। लेकिन पिछले अनुभव बताते हैं कि आम तौर पर इस तरह की बातें अनसुनी हो जाती हैं।

किसी भी तरह से, प्रमुख संस्करण या नहीं, आप शायद "इसे जाने दो" के लिए मजबूर होने के साथ समाप्त हो जाएंगे और देखें कि क्या टूटता है।

हालांकि मुझे गलत मत समझो: रिफ्लेक्टर एक बहुत अच्छी बात है। आगे बढ़ते हुए इसे आम तौर पर रखरखाव के बोझ से एक अच्छा टुकड़ा लेना चाहिए।

जैसे, अगर कोई आपकी लाइब्रेरी के प्रोटोटाइप को हैक कर लेता है, तो आप उसके लिए रक्षात्मक तरीके से कोड कैसे करते हैं ??

आप सचमुच नहीं करते हैं।

यह शिकायत करने वाले लोगों की तरह है कि मामूली रिलीज में सी # ब्रेक में निजी सदस्यों तक पहुंचने के लिए उनके सावधानीपूर्वक ऑर्केस्ट्रेटेड रनटाइम-उत्सर्जित आईएल। यदि आप आंतरिक के साथ हस्तक्षेप करते हैं, तो आपको पता होना चाहिए कि आप क्या खरीद रहे हैं। :मुस्कुराओ:

@rjgotten रिफैक्टरिंग की बात कर रहे हैं ...

..... कम कोडबेस में मैंने समय के साथ जो कुछ खोजा है, वह यह है कि ऐसे कई स्थान हैं जहां एएसटी में वस्तुओं पर मामूली/सूक्ष्म उत्परिवर्तन होते हैं। यहां एक नई संपत्ति / एक उदाहरण पर एक अतिरिक्त विधि, और मैं इसे कई बार उन विशेषताओं के साथ करने के लिए पूरी तरह से स्वीकार करूंगा, जिनमें मैंने विलय किया है, क्योंकि जावास्क्रिप्ट में, आप जो चाहें, जब चाहें, चाहे आप जो चाहें, बदल सकते हैं। उस संपत्ति का दस्तावेज/परिभाषित किया गया है या नहीं।

इस बारे में कुछ चर्चा हुई कि टाइपस्क्रिप्ट बनाम सिर्फ आधुनिक जेएस ही इसका उत्तर होगा। मैंने महसूस किया है कि टाइप या स्पष्ट ऑब्जेक्ट इंटरफेस नहीं होने से कम कोडबेस कई बार इस तरह से तर्क करना बहुत कठिन हो जाता है कि कोई भी दस्तावेज हल नहीं कर सकता है या यहां तक ​​​​कि JSDocs भी हल नहीं कर सकता है।

मैंने टाइपस्क्रिप्ट लाइनिंग की अनुमति देने के लिए नई पाइपलाइन स्थापित की है _if_ आपके पास JSDoc में उचित प्रकार हैं, लेकिन टाइपिंग के लिए JSDoc का उपयोग करना टाइपस्क्रिप्ट की तुलना में अधिक वर्बोज़ / नेत्रहीन शोर है, और कुछ टाइपिंग विशेषताएं हैं जो TS केवल JSDoc एनोटेशन के माध्यम से समर्थन नहीं करती हैं। . कोई JSDoc / ESLint उपकरणों का संयोजन नहीं है जो इनमें से कुछ चीजों को हल कर सकता है जो TS आपको मुफ्त में देता है।

इसलिए, मुझे लगता है कि मैं केवल इतना कह रहा हूं कि पिछले वर्ष में टाइपस्क्रिप्ट का महत्वपूर्ण रूप से उपयोग करने के बाद, और कम कोडबेस में वर्षों बिताने के बाद, मैं कहूंगा कि 95% भ्रम/निराशा/सीखने की अवस्था का पता लगाना है कि कम कैसे काम करता है यदि वस्तुओं में संकलन-समय प्रकार लागू किए गए हों तो टाला जा सकता है। मैंने अक्सर डिबगर में बहुत समय बिताया है, बस ब्रेकपॉइंट्स सेट करना और यह पता लगाना कि किसी ऑब्जेक्ट के गुण _actually_ क्या हैं, इसके बजाय इसे फ़ाइल में कैसे परिभाषित किया जाता है।

उदाहरण के लिए, कई विशेषताएं हैं जो कम में मूल्यांकन के दौरान Ruleset नोड की paths संपत्ति पर निर्भर करती हैं। इस कंस्ट्रक्टर से, क्या आप मुझे बता सकते हैं कि paths संपत्ति क्या है, और इसका आकार क्या होगा? (संकेत: आप नहीं कर सकते, क्योंकि यह वहां नहीं है।)

टाइपस्क्रिप्ट में (सामान्य tsconfig सेटिंग्स के साथ), इसकी अनुमति नहीं होगी। यह संकलित भी नहीं होगा। आपको paths के आकार को निर्दिष्ट करने के लिए मजबूर किया जाएगा, और वास्तव में इसमें क्या होगा, जो बदले में कोडबेस की खोज करने वाले किसी व्यक्ति को स्पष्ट, विशिष्ट दस्तावेज (और कोड संकेत) देगा।

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

मैं बस यही सोच रहा हूं कि यहां से कहां जाना है, और भविष्य में दर्द के बिंदुओं को रोकने के तरीके।

_( परिशिष्ट : यदि यह स्पष्ट नहीं है, तो मैं 100% कम कोडबेस में किसी के ऐतिहासिक कार्य को कोस नहीं रहा हूं। ऐसी कई चीजें हैं जिन्हें मैंने प्रस्तावित किया है, खरीद-इन किया है, और कोडबेस में विलय कर दिया है कि अब मैं मुझे पसंद है, "उफ़, काश मैंने ऐसा नहीं किया होता," या काश मैंने इसे अलग तरीके से किया होता। और मैंने निश्चित रूप से उन चीजों को जोड़ा है जो मुझे एहसास है कि अब रखरखाव पर नकारात्मक प्रभाव पड़ सकता है। सभी ने अपना सर्वश्रेष्ठ किया है।)_

@ मैथ्यू-डीन
यदि आपके पास JSDoc में उचित प्रकार हैं, तो टाइपस्क्रिप्ट लाइनिंग की अनुमति देने के लिए मैंने नई पाइपलाइन स्थापित की है, लेकिन टाइपिंग के लिए JSDoc का उपयोग करना टाइपस्क्रिप्ट की तुलना में अधिक वर्बोज़ / नेत्रहीन शोर है, और कुछ टाइपिंग विशेषताएं हैं जो TS केवल JSDoc एनोटेशन के माध्यम से समर्थन नहीं करती हैं। . कोई JSDoc / ESLint उपकरणों का संयोजन नहीं है जो इनमें से कुछ चीजों को हल कर सकता है जो TS आपको मुफ्त में देता है।

वास्तव में; मैं JSDoc समर्थन के साथ इस मुद्दे पर भाग गया, इसलिए स्वयं प्रकार के अनुमान के लिए भी।
सौभाग्य से आप .d.ts घोषणा फ़ाइलों का उपयोग .js स्रोत फ़ाइलों के बगल में कर सकते हैं, बिना पूर्ण टाइपस्क्रिप्ट पर जाने और संकलक की आवश्यकता के बिना।

डिक्लेरेशन फाइलों के साथ काम करना बहुत कठिन हुआ करता था, लेकिन टाइपस्क्रिप्ट के कंपाइलर के आधुनिक संस्करण स्वचालित रूप से .d.ts फ़ाइल को .js फ़ाइल के साथ-साथ जोड़ देंगे, जब तक दोनों का नाम दिया जाता है वही।

हो सकता है कि आप यही खोज रहे हों।

@rjgotten क्या आप थोड़ा और समझा सकते हैं (या यदि आप एक अच्छा संसाधन जानते हैं तो लिंक करें), यह कैसे कम कोडबेस के साथ अच्छी तरह से काम कर सकता है? जैसा कि, आप फ़ाइल स्तर पर फ़ाइल पर इसे कैसे करते हैं? क्या कोई .d.ts फ़ाइल प्रति .js मॉड्यूल है? या आप उन्हें समूहित करते हैं?

.d.ts फ़ाइल बनाम केवल स्रोत में टाइपस्क्रिप्ट का उपयोग करने के क्या लाभ हैं? फ़ाइलों में केवल उन प्रकारों को परिभाषित करने के बजाय .d.ts फ़ाइलें बनाने में समय क्यों व्यतीत करें?

@rjgotten मैं आज शेवरोटेन के डेवलपर से बात कर रहा था, और वह कहता है कि वह जो करता है वह TS _BUT_ में विकसित होता है, वह वास्तव में एक अलग चिंता के रूप में api.d.ts फ़ाइल का प्रबंधन करता है। इस तरह, स्रोत फ़ाइलों (जैसे ट्री नोड्स) पर प्रकार का कोई भी परिवर्तन एपीआई प्रकार फ़ाइल के स्पष्ट परिवर्तन के बिना सार्वजनिक एपीआई को पारदर्शी/अदृश्य रूप से नहीं बदलता है।

फिर वह एक परीक्षण का उपयोग इस दावे के साथ करता है कि आंतरिक प्रकार और सार्वजनिक एपीआई प्रकार मेल खाते हैं -> https://github.com/SAP/chevrotain/blob/master/packages/chevrotain/test_integration/definitions/api_type_checking.ts#L1 - एल2

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

$#$0$ .js टंकण रखने के लिए .d.ts घोषणा फाइलों के उपयोग के संबंध में:
यह वास्तव में दोनों है।

यदि वे साथ-साथ चलते हैं, तो कोई भी IDE जो ऑटो-सुझाव, लाइनिंग आदि के लिए टाइपस्क्रिप्ट कंपाइलर द्वारा समर्थित है, स्वचालित रूप से टाइपिंग पर ध्यान देगा। Afaik _also_ यदि साथ-साथ टाइपिंग वाली वे स्क्रिप्ट node_modules से आयात की जाती हैं, जो काफी अच्छी है।

आप टाइपिंग को एकल (सेट) .d.ts फ़ाइल (फ़ाइलों) जैसे api.d.ts में भी डाल सकते हैं और फिर घोषित प्रकारों को स्पष्ट रूप से आयात करने के लिए JSDoc का उपयोग कर सकते हैं। टाइपस्क्रिप्ट में JSDoc समर्थन में आयात सिंटैक्स के साथ @typedef का विशेष स्वाद है। उदाहरण के लिए

/**
 * <strong i="17">@typedef</strong> {import("../api.d.ts").MyType } MyType
 */

यदि आपको वितरण से पहले अपने पैकेज को ट्रांसपिलिंग चरण के माध्यम से ले जाना है तो एकल बंडल टाइपिंग फ़ाइल का उपयोग करना एक अच्छा विचार है। ऐसे मामले में जो उपयोगकर्ता वास्तव में require() या import {} मूल स्रोत फ़ाइलें नहीं होंगे। यानी उन्हें साथ-साथ टाइपिंग से कोई फायदा नहीं होगा।