Definitelytyped: मोनोरेपो क्यों?

1. आप types अंतर्गत सीधे फ़ोल्डर में नेविगेट कर सकते हैं। उदाहरण के लिए, jquery के प्रकार देखने के लिए, https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/jquery पर नेविगेट
2. आप पुस्तकालय का नाम खोज सकते हैं। उदाहरण के लिए, यदि आप lodash से संबंधित खुले मुद्दों की खोज करना चाहते हैं, तो आप https://github.com/DefinitelyTyped/DefinitelyTyped/issues?utf8=%E2%9C%93&q=is% पर जा सकते हैं।

क्या यह मोनोरेपो कुल गड़बड़ नहीं है?

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

नॉन-मोनोरेपो नॉन-स्टार्टर है। अक्सर, एक @types पैकेज में कुछ संशोधित करने वाले योगदानकर्ताओं को ब्रेक को ठीक करने या नई कार्यक्षमता को सक्षम करने के लिए कई डाउनस्ट्रीम पैकेजों को संशोधित करने की आवश्यकता होगी; यह गिटहब के वर्कफ़्लो के साथ एक पूर्ण डंपस्टर आग है क्योंकि उन पीआर को परमाणु फैशन में विलय करने का कोई एकीकृत तरीका नहीं है, जबकि अभी भी समझदार सीआई चल रहा है। यदि आपको लगता है कि आप 4,000 फ़ोल्डरों को देखना एक समस्या है, तो कल्पना कीजिए कि हम 4,000 रेपो में गिटहब सेटिंग्स को सिंक्रनाइज़ रखने की कोशिश कर रहे हैं।

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

मैं @types/ पैकेज लिखने से परिचित नहीं हूं, इसलिए हो सकता है कि मुझे कुछ याद आ रहा हो ...

लेकिन क्या यह नहीं है कि सेवर किस लिए है?
एनपीएम में किसी अन्य पैकेज के मुकाबले @types/ पैकेज को लागू करने में ऐसा क्या खास है?

मैं उम्मीद करता हूं कि यह वही काम करे: निर्भरता ग्राफ जहां आपके पास है। पैकेज @types/X और डाउनस्ट्रीम पैकेज @types/Y जो @types/X का उपयोग करता है। दोनों का रखरखाव अलग-अलग लोगों ने किया। जब @types/X बदल जाता है, तो इसे अलग संस्करण के साथ प्रकाशित किया जाता है, इसलिए यह तुरंत @types/Y को प्रभावित नहीं करेगा। @types/Y योगदानकर्ता बाद में @types/X नए संस्करण में अपडेट करने का निर्णय लेते हैं और सभी ब्रेकिंग परिवर्तनों के कारण समस्याओं को ठीक करते हैं।

शायद उसके ऊपर आपके पास DefinitelyTyped मेटा-रिपॉजिटरी है, जो केवल टाइप-रेपो के लिंक की सूची रखता है। और फिर कुछ publisher स्क्रिप्ट जो उस सूची में जाती है और @types/ npm-namespace के तहत सभी पैकेज प्रकाशित करती है।

या यदि यह संभव है, तो कार्यान्वयनकर्ताओं को सीधे @types नामस्थान के अंतर्गत प्रकाशित करने की अनुमति दें। इसलिए हमें DefinitelyTyped मेटा-रेपो की बिल्कुल भी आवश्यकता नहीं है।

https://github.com/npm/npm भी 2k अंक।
https://github.com/moby/moby और भी अधिक।

सबसे अच्छा समाधान लेखक की परिभाषा को बनाए रखना है, जिसे हमेशा प्रोत्साहित किया गया है।

@franklinyu मुद्दों की संख्या वह नहीं है जो प्रश्न के अधीन है। इस रेपो समुच्चय> 4k टाइपिंग को ध्यान में रखते हुए, बड़ी संख्या में मुद्दे ठीक हैं।

असली सवाल यह है: एक रेपो में सभी टाइपिंग को जोड़कर DefinitelyTyped किस समस्या को हल करने की कोशिश कर रहा है?

दुर्भाग्य से, टाइपिंग पैकेज के लिए सेवर अच्छी तरह से काम नहीं करता है। प्रकार पैकेज के major.minor संस्करण को जावास्क्रिप्ट पैकेज के major.minor से मेल खाना चाहिए, अन्यथा लोगों को पता नहीं होगा कि किसी दिए गए जावास्क्रिप्ट पैकेज संस्करण के लिए कौन सा @types संस्करण का उपयोग करना है।

उदाहरण के लिए, अभी यदि आप [email protected] इंस्टॉल करते हैं, तो आप @types/[email protected] भी इंस्टॉल करेंगे (अभी यह 4.14.109 )। हालांकि, कल्पना करें कि lodash प्रकारों में एक बग है (और मेरा विश्वास करो ऐसा अक्सर होता है), और कोई इसे ठीक करता है। अब हम संस्करण संख्या को किससे टकराते हैं? परिभाषा के अनुसार, प्रकार की परिभाषाओं में कोई भी परिवर्तन एक इंटरफ़ेस ब्रेकिंग परिवर्तन (या कम से कम एक इंटरफ़ेस जोड़) है। लेकिन हम संस्करण को 4.15.0 नहीं बढ़ा सकते क्योंकि ये प्रकार 4.14 , न कि 4.15 । और हम निश्चित रूप से संस्करण संख्या को 5.0.0 से टकराना नहीं चाहते हैं। इसलिए इसके बजाय हम संस्करण संख्या को 4.14.110 , भले ही एक इंटरफ़ेस परिवर्तन हुआ हो, क्योंकि वास्तव में पुराना इंटरफ़ेस बिल्कुल गलत था।

@ aj-r ठीक है, major.minor का @type/X major.minor संस्करण X संस्करण के बराबर होना चाहिए, और यदि @type/X में कोई बग है patch संस्करण का उपयोग करते हैं। यह सही लगता है।

इसका मूल प्रश्न से क्या लेना-देना है: मोनोरेपो बनाम अलग रेपो?

क्षमा करें, मुझे स्पष्ट होना चाहिए था - मैं आपकी पिछली टिप्पणियों में से एक को संबोधित कर रहा था:

लेकिन क्या यह _semver_ के लिए नहीं है?

एक रेपो में सभी टाइपिंग को एकत्रित करके हल करने की कोशिश कर रहे निश्चित रूप से टाइप की गई समस्या क्या है?

डीटी को 4,000 अलग-अलग गिटहब रेपो में हल करने के हल हो रही है?

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

इसे हजारों सबरेपो में विभाजित करने से यह सब कठिन हो जाता है, और कुछ भी आसान नहीं होता है। तो हम ऐसा क्यों करेंगे?

डीटी को 4,000 अलग-अलग गिटहब रेपो में हल करने के लिए कौन सी समस्या हल हो रही है?

1. एक उपयोगकर्ता के रूप में आप स्रोतों तक तेजी से पहुंचते हैं। स्रोतों तक पहुंचने के लिए आपको टाइपसर्च जैसे कुछ अतिरिक्त ऐप का उपयोग करने की आवश्यकता नहीं है। NPM पर आपके पास सीधे आवश्यक टाइपिंग-रेपो का लिंक होता है।

2. एक उपयोगकर्ता के रूप में वर्तमान मुद्दों को देखना और नई फाइल करना आसान है।

   • आपको> 2k मुद्दों के साथ एक विशाल रेपो पर खोज और फ़िल्टर करने की आवश्यकता नहीं है। क्या होगा यदि रिपोर्टर समस्या नामकरण नियमों का पालन करना भूल जाता है (अर्थात [@types/name-of-package] Issue description )? आपको आवश्यक मुद्दे कभी नहीं मिलते हैं।
   • ऐसे में डुप्लीकेट फाइल करना कम संभव है।

3. एक योगदानकर्ता के रूप में आप स्पष्ट रूप से देख सकते हैं कि आपके भंडार में कितने मुद्दे हैं।

   • अपने ठोस टाइपिंग के लिए समस्याएँ प्राप्त करने के लिए आपको (फिर से) कुछ भी फ़िल्टर करने की आवश्यकता नहीं है। आवश्यक मुद्दों को याद करना कम संभव है।
   • मुद्दों को कम रखने के लिए आपके पास स्पष्ट प्रेरणा है। मुद्दे संख्या अब साझा जिम्मेदारी नहीं है।
   • ऐसे में यह संभव नहीं है कि वर्षों से वहां लटके मुद्दों को भुला दिया जाए।
     उदा. 2013 से 1 अंक पृष्ठ है, 2014 से 5 अंक पृष्ठ हैं, और इसी तरह।

4. टाइपस्क्रिप्ट टीम के सदस्य के रूप में आपने बहुत सारे npm पैकेजों के लिए हजारों टाइपिंग को बनाए रखने/विलय/समीक्षा करने के बजाय, टाइपस्क्रिप्ट को बेहतर बनाने पर अधिक समय बिताया (उदाहरण के लिए। jsdoc समर्थन)।
   परिपक्व पारिस्थितिकी तंत्र में समुदाय को यही करना चाहिए।

   • हम रेपो-वाइड लिंट नियम चलाते हैं जो सामान्य त्रुटियों को पकड़ते हैं

     सभी अनुशंसित नियमों के साथ लिंट प्रीसेट को अच्छी तरह से रिलीज़ करें, और सभी योगदानकर्ताओं को उस प्रीसेट के नवीनतम संस्करण का उपयोग करने की सलाह दें।

   • हम भविष्य के कंपाइलर संस्करणों द्वारा टूटी हुई चीजों के साथ परिभाषाएं ढूंढते हैं और ठीक करते हैं।

     यही समुदाय योगदानकर्ताओं को करना चाहिए। टाइपिंग-पैकेज के package.json के peerDependency अनुभाग में अपेक्षित ts-compiler के संस्करण को स्पष्ट रूप से बताया जाना चाहिए, इसलिए जब आप इसे गलत वातावरण में उपयोग करते हैं तो यह आपको चेतावनी देता है।

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

क्या होता है जब इन रेपो में से किसी एक का तदर्थ स्व-घोषित "मालिक" इसे बनाए रखना बंद करने का निर्णय लेता है? ऐसा हर समय होता है। हम कैसे ट्रैक करते हैं कि कौन सा रेपो वर्तमान "सर्वश्रेष्ठ" है? क्या होता है यदि वे उन परिवर्तनों को मर्ज करना शुरू कर देते हैं जिनके परिणामस्वरूप हम NPM पर प्रकाशित नहीं कर सकते हैं?

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

टाइपस्क्रिप्ट टीम के सदस्य के रूप में आपने बहुत सारे npm पैकेजों के लिए हजारों टाइपिंग को बनाए रखने/विलय/समीक्षा करने के बजाय, टाइपस्क्रिप्ट को बेहतर बनाने पर अधिक समय बिताया (उदाहरण के लिए। jsdoc समर्थन)। परिपक्व पारिस्थितिकी तंत्र में समुदाय को यही करना चाहिए।

हमने सचमुच यह कोशिश की और यह काम नहीं किया। डीटी पूरी तरह से समुदाय संचालित था और इसके परिणामस्वरूप सैकड़ों गहरे पुल अनुरोध बैकलॉग हुए। तब से पीआर को मर्ज करने का औसत समय 2 सप्ताह से गिरकर 4 दिन हो गया है (जो जानबूझकर न्यूनतम है इसलिए लोगों के पास परिवर्तनों पर वजन करने का समय है), भले ही पीआर वॉल्यूम ~ 200/माह से ~ 1,000/माह हो गया हो .

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

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

लेकिन अगर यह मॉडल आपके काम आता है। फिर ठीक है: स्माइली:

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