Rollup-plugin-typescript2: डिफ़ॉल्ट tsconfig विकल्प "शामिल करें" मूल tsconfig.json से अनुक्रमणिका द्वारा ओवरराइड किया गया है

यह include करना असंभव बनाता है क्योंकि आप कभी नहीं जानते कि tsconfig.json में सरणी कितनी देर तक होगी

दिलचस्प बात यह है कि,
अगर मैं typescript2 config include विकल्प को tsconfigDefaults से tsconfigOverride स्थानांतरित करता हूं
यह इंडेक्स द्वारा मूल tsconfig.json include विकल्प को ओवरराइड कर देगा।

यानी यह बिल्कुल विपरीत है
लेकिन यह भी बहुत बुरा है

एक और बात
कुछ अतिरिक्त जांच के बाद
मुझे एहसास हुआ कि वही व्यवहार अन्य सरणी गुणों के लिए भी प्रासंगिक है

इसलिए मैंने इस मुद्दे को पहले https://github.com/jaredpalmer/tsdx/pull/666#discussion_r404847759 में मारा है, और उस मुद्दे के अनुसार, _.merge का डीप मर्ज काम करता है। यह एक गहरा विलय है इसलिए यह सरणी विलय करता है और अनुक्रमणिका सरणी का एकमात्र पहचानकर्ता है। यह _अनपेक्षित_ हो सकता है लेकिन यह एक गहरा विलय है, इस तरह गहरा विलय काम करता है।

वास्तव में, यह इन गुणों को संयोजित नहीं करता है, लेकिन सूचकांक सेल में मानों को बदल देता है ,

• इसके बजाय एक एपेंड/कॉनकैट करना बिल्कुल विलय नहीं होगा, और tsconfig साथ ओवरराइट करने का कोई तरीका नहीं देगा। यह मेरे लिए गलत व्यवहार की तरह लगता है।
• इसके बजाय एक उथला विलय करने से डिफ़ॉल्ट में जो कुछ भी है, उसे ओवरराइट कर दिया जाएगा, जो मुझे यकीन नहीं है कि अपेक्षित व्यवहार भी है, लेकिन यह tsconfig के संबंध में कैसे काम करता exclude , यह डिफ़ॉल्ट को अधिलेखित कर देता है।

मैं केवल include और exclude पर उथला विलय करने के लिए एक पीआर लिख सकता था, लेकिन यह _pretty_ एक बदलाव को तोड़ना होगा; मुझे नहीं पता कि यह सभी डाउनस्ट्रीम उपयोगकर्ताओं को कैसे प्रभावित कर सकता है। Idk यदि TSDX उपयोगकर्ता उथले या गहरे विलय की अपेक्षा करते हैं, लेकिन यदि गहरी अपेक्षा की जाती है तो यह उनके उपयोग को तोड़ देगा।

अगर मैं typescript2 config include विकल्प को tsconfigDefaults से tsconfigOverride स्थानांतरित करता हूं
यह इंडेक्स द्वारा मूल tsconfig.json include विकल्प को ओवरराइड कर देगा।

यानी यह बिल्कुल विपरीत है

हां, इस तरह tsconfigOverride को काम करना चाहिए, यह एक ओवरराइड है।

मुझे एहसास हुआ कि वही व्यवहार अन्य सरणी गुणों के लिए भी प्रासंगिक है

हां, इस तरह _.merge एक गहरा विलय करता है, इसलिए tsconfig जो कुछ भी एक सरणी है, वही परिवर्तन होता है।

@ agilgur5 प्रतिक्रिया के लिए धन्यवाद!

1) मेरे दृष्टिकोण से, यह व्यवहार कॉन्फ़िगरेशन को पूरी तरह से बेकार बना देता है। यदि हम सरणी में किसी स्थिति से बंधे हैं तो हम कॉन्फ़िगरेशन की विश्वसनीयता की गारंटी नहीं दे सकते हैं।

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

इस चीज़ को संभालने के लिए मेरी जेब में एक चाल है, लेकिन यह स्वच्छ कोड परिप्रेक्ष्य से शोर दिखता है - बस tsconfig पढ़ें, include संपत्ति प्राप्त करें और इसे मेरी सरणी से जोड़ दें। ऐसा लगता है कि यह आसान होना चाहिए।

मेरा सुझाव:
1) डिफ़ॉल्ट रूप से - डिफ़ॉल्ट संपत्ति एकत्र करें और मूल tsconfig के साथ संयोजित करें; डुप्लिकेट निकालें।
2) ओवरराइड के लिए - केवल ओवरराइड विकल्प लागू करें

ओवरराइड होने पर डिफ़ॉल्ट सामान्य रूप से संयोजित नहीं होते हैं, वे ओवरराइड हो जाते हैं। और जैसा कि मैंने ऊपर उल्लेख किया है, संयोजन tsconfig साथ डिफ़ॉल्ट को ओवरराइड करने के लिए इसे _impossible_ बनाता है। यह मेरे लिए कई तरह से गलत व्यवहार की तरह लगता है, इसलिए मैं इसे दृढ़ता से हतोत्साहित करता हूं।

मुझे लगता है कि सभी विकल्प भ्रमित कर रहे हैं, मुझे यकीन नहीं है कि मैं सहमत हूं कि इनमें से कोई भी "सर्वश्रेष्ठ डीएक्स" है। tsconfig अपने डिफ़ॉल्ट exclude साथ कैसे काम करता है, इसके लिए एक उथला विलय निकटतम चीज है, लेकिन यह ट्रेड-ऑफ के बिना नहीं आता है।
सामान्य तौर पर, परिवर्तनों को तोड़ने के लिए उन पर बहुत अधिक विचार करने की आवश्यकता होती है, यही वजह है कि मैंने इसे ऊपर लाया - डाउनस्ट्रीम प्रभाव गैर-तुच्छ हैं; TSDX को इस तरह के बदलाव को अपडेट करने के लिए एक ब्रेकिंग बदलाव भी जारी करना होगा।

@ agilgur5 ठीक है, तो मैं या तो डिफ़ॉल्ट या ओवरराइड का उपयोग नहीं कर सकता।
कारण? इस बात की कोई गारंटी नहीं है कि उस इंडेक्स पर कोई वैल्यू नहीं लिखी जाएगी।
इसके अलावा, आप सरणी के मान के रूप में अपरिभाषित के माध्यम से चारों ओर प्राप्त कर सकते हैं, और अपना आवश्यक मान आगे जोड़ सकते हैं। और यह पता चला है कि इस प्रणाली में एक अंतर है? सिर्फ महान।

मामला:

1. मैं अपने अतिरिक्त d.ts टाइपिंग को "शामिल" कॉन्फिग संपत्ति के अंदर जोड़ना चाहता हूं।
2. उपयोगकर्ता अपने डालता है src एक अन्य परियोजना विशिष्ट साथ निर्देशिका के अंदर "शामिल हैं" d.ts बाहर typings src ।

1. ['config.d.ts`]
   2. ['src', 'some.d.ts', 'another.d.ts']
2. परिणाम: ['src', 'some.d.ts', 'another.d.ts']

जैसा कि आप देख सकते हैं, इसे ठीक से कॉन्फ़िगर करने का कोई तरीका नहीं है। मुझे tsconfig.json पढ़ना चाहिए, इसकी "शामिल" संपत्ति प्राप्त करनी चाहिए और इसे ['src', 'some.d.ts', 'other.d.ts', 'config.d.ts'] में मिला देना चाहिए।
और मुझे लगता है कि यह एक पूर्ण उपरि है।

इस बीच, मुझे पता चला कि समस्या क्या है। अन्य लोग इसका पता नहीं लगा सकते हैं और अपना कीमती समय यह पता लगाने में लगा सकते हैं कि उनके लिए क्या काम नहीं करता है।
और आपके पहले संदेश के बाद, मैंने पहले ही कम से कम 2 संबंधित मुद्दों को देखा है। और यह चलता रहेगा।

मैं इसे इसलिए देखता हूं कि अगर हम सब कुछ वैसे ही छोड़ दें, तो मैं इसका उपयोग नहीं कर सकता, यह मेरे लिए एक ब्लैक बॉक्स है क्योंकि मैं कुछ भी गारंटी नहीं दे सकता।
व्यक्तिगत प्राथमिकताओं के लिए "पसंद" / "नापसंद" के लिए कोई जगह नहीं है।
यह या तो इस्तेमाल किया जा सकता है या नहीं। और यह नहीं हो सकता।

मुझे इसमें शामिल अन्य लोगों की राय लेने में कोई दिक्कत नहीं है।
और एक और बात, मुझे वर्तमान समाधान के साथ रहने में कोई समस्या नहीं है, मेरे पास ऊपर वर्णित हैक है, जिसके साथ मैं रहने के लिए तैयार हूं। लेकिन मुझे यह समझ में नहीं आता कि इस समाधान को पारदर्शी बनाने में क्या समस्या है, इस तथ्य से बंधे बिना कि इसमें परिवर्तनकारी बदलाव होंगे।

मेरा मतलब है, आप यहां अपनी पसंद दे रहे हैं, जबकि मैंने पहले से ही कई अलग-अलग विकल्प दिए हैं। मैंने पहले ही दो बार कहा है कि वरीयता, संयोजन, मौलिक रूप से क्यों टूटा हुआ है, इसी तरह अनजान है, और बिल्कुल "पारदर्शी" नहीं है। दोहराने के लिए, संयोजन _just_ एक ब्रेकिंग परिवर्तन नहीं है, यह सचमुच चीजों को ओवरराइड करना असंभव बनाता है। मैं फिर दोहराऊंगा, असंभव ।
संयोजन के साथ ओवरराइड करना असंभव होना "वरीयता" नहीं है, यह एक तथ्य है।

दोबारा, एक "डिफ़ॉल्ट" जिसे ओवरराइड नहीं किया जा सकता है वह डिफ़ॉल्ट नहीं है, यह एक आवश्यकता है। "डिफ़ॉल्ट" को आवश्यकता में बदलने का कोई मतलब नहीं है और यह गलत व्यवहार है।

आप अभी डीप मर्ज को ओवरराइड कर सकते हैं, आप कॉन्सटेनेशन को ओवरराइड नहीं कर सकते। मौजूदा उपयोग-मामले को असंभव बनाना समझ में नहीं आता है।

मैंने पहले ही दो बार एक वैकल्पिक विकल्प दिया है जो मूल रूप से टूटा नहीं है, जो एक उथला विलय है। मैं फिर से दोहराऊंगा, आप इसे हल करने के लिए उथले मर्ज का भी उपयोग कर सकते हैं।
क्या यह बेहतर है बहस का विषय है। हर चीज के लिए ट्रेड-ऑफ हैं।

मैंने पहले बग्स को ठीक करने के लिए यहां योगदान दिया है (मुझे पता है कि यह _.merge क्योंकि मैंने कोडबेस पढ़ा है) और मेरे द्वारा बनाए रखा एक पुस्तकालय इस पुस्तकालय (~ 10%) के उपयोग का एक महत्वपूर्ण हिस्सा बनाता है, मैं हूं यहां सिर्फ बातें नहीं कर रहे हैं...

उल्लेख नहीं है, इसे परिवर्तनों को तोड़े बिना हल किया जा सकता है - आप tsconfigConcat या tsconfigDefaultShallow आदि के लिए एक नया विकल्प जोड़ सकते हैं।

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

मुझे लगता है कि हमें चीजों को तोड़ना होगा चाहे हम यहां कुछ भी करें। इसे दस्तावेज़ीकरण और संपत्ति के नाम की भावना के अनुसार व्यवहार करने के लिए इसे मूल रूप से यह करना चाहिए:

• tsconfigDefaults - यह वह वस्तु है जो नीचे दी गई हर चीज में गहराई से विलय हो जाएगी
• tsconfig - यह वह वस्तु है जो हमें टाइपस्क्रिप्ट से प्राप्त होती है, इसके अपने आयात और सब कुछ के बाद। यहां सभी मान tsconfigDefaults में मानों को प्रतिस्थापित करते हैं। यहाँ सभी सरणियों में सरणियों के साथ concatenated रहे हैं tsconfigDefaults ।
• tsconfigOverride - यह परमाणु विकल्प है। ऑब्जेक्ट्स अभी भी गहराई से विलय कर दिए गए हैं, लेकिन यहां सरणी थोक सरणी को प्रतिस्थापित करती है । इसलिए यदि आप यहां एक खाली शामिल सरणी प्रदान करते हैं, तो अंतिम tsconfig में कोई भी शामिल नहीं होगा।

क्या यह उन सभी मामलों को कवर करेगा जिनका हम समर्थन करना चाहते हैं (उपयोगकर्ताओं द्वारा उचित परिवर्तन करने के बाद), या क्या मुझे कुछ याद आ रहा है?

@ezolenko अद्भुत लगता है और उपयोग करने के लिए बहुत मायने रखता है

@ezolenko मुझे यकीन नहीं है कि आपको चीजों को क्यों तोड़ना है? मैंने ऐसे विकल्प दिए हैं जो पहले से ही नॉन-ब्रेकिंग हैं।

मुझे यकीन नहीं है कि आपने जो सूचीबद्ध किया है वह "दस्तावेज़ीकरण और संपत्ति के नामों की भावना" को दर्शाता है क्योंकि दस्तावेज़ कहते हैं:

tsconfigDefaults रूप में पारित वस्तु को लोड किए गए tsconfig.json साथ विलय कर दिया जाएगा। टाइपस्क्रिप्ट में पारित अंतिम कॉन्फ़िगरेशन tsconfigDefaults में मानों का परिणाम होगा लोड किए गए tsconfig.json में मानों द्वारा प्रतिस्थापित किया गया
[...]
यह एक डीप मर्ज है (ऑब्जेक्ट्स को मर्ज किया जाता है , सरणियों को जोड़ा जाता है, आदिम को बदल दिया जाता है , आदि), verbosity से 3 तक बढ़ाएं और अगर आपको कुछ अप्रत्याशित मिलता है तो parsed tsconfig ।

यह "विलय", "प्रतिस्थापित", और "डीप मर्ज" कहता है, जिनमें से सभी का अर्थ डिफ़ॉल्ट को प्रतिस्थापित और ओवरराइड करना है। "सम्मिलित" का एक ही संदर्भ है जो बाकी_ से _भिन्न है, लेकिन एक गहरा विलय वास्तव में _not_ करता है। 5 संदर्भ एक बात कहते हैं और छठा गलत है। मेरे लिए, ऐसा लगता है कि ६ वां संदर्भ जो गलत है उसे ठीक किया जाना चाहिए, न कि ५ सही लोगों को गलत ६ में बदला जाना चाहिए।

lodash वास्तविक मानक है और विलय की इसकी परिभाषा _not_ को संयोजित करने के लिए है। डिफ़ॉल्ट की परिभाषा यह है कि जब आप समान गुण मान सेट करते हैं, तो _not_ संयोजित होने पर वे ओवरराइड हो जाते हैं:

_.defaults({ a: ['a'] }, { a: ['b', 'c'] });
// => {a: ['a']}
_.defaultsDeep({ a: ['a'] }, { a: ['b', 'c'] });
// => {a: ['a', 'c']}

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

यह समरूपता को tsconfigOverride साथ-साथ अपने स्वयं के दस्तावेज़ों के साथ भी तोड़ता है:

• tsconfigOverride : {}
tsconfigDefaults ।

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

जैसा कि मैंने कहा है, सरणियों का उथला विलय अधिक सहज हो सकता है, क्योंकि tsconfig _itself_ वास्तव में कैसे काम करता है। जैसा कि मैंने ऊपर लिंक किया है, tsconfig _itself_ जब आप एक exclude जोड़ते हैं तो यह संयोजित नहीं होता है, यह मौजूदा exclude ओवरराइड करता है।

तो concatenate पहले से ही दस्तावेज़ों में 5+ संदर्भों से मेल नहीं खाता है, मर्ज की परिभाषा, डिफ़ॉल्ट की परिभाषा, और न ही tsconfig का अपना व्यवहार। और यह अन्य विकल्पों की समरूपता और डॉक्स को तोड़ता है। मुझे यकीन नहीं है कि यह कैसे सहज है।

और जैसा कि मैंने कई बार कहा है, इसे ओवरराइड करने के बजाय एक बहुत ही सहज ज्ञान युक्त संयोजन बनाने से कुछ मामलों का उपयोग

https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

आशय यह है कि यदि आप अपना स्वयं का exclude जोड़ते हैं, तो यह हमारे द्वारा सेट किए गए डिफ़ॉल्ट को ओवरराइड करता है। डिफ़ॉल्ट केवल तभी लागू होते हैं जब आपने संपत्ति का नाम सेट नहीं किया है, बस हर दूसरे संपत्ति के नाम की तरह (फिर से, यह डिफ़ॉल्ट की परिभाषा है और सभी पुस्तकालयों में डिफ़ॉल्ट कैसे काम करता है)।

यदि आप इसे बदलने के लिए बदलना चाहते थे, तो उपयोगकर्ता के पास अब हमारे डिफ़ॉल्ट exclude को ओवरराइड करने का कोई तरीका नहीं है, यह उनके लिए डिफ़ॉल्ट को ओवरराइड करने के लिए _impossible_ है । हम tsconfig के डिफ़ॉल्ट exclude को भी शिप करते हैं, इसलिए यह tsconfig के डिफ़ॉल्ट को ओवरराइड करना _impossible_ भी बनाता है, भले ही tsconfig _itself_ आपको ऐसा करने देता है उस।

मुझे यकीन नहीं है कि मैं यहां _मौजूदा परिभाषाओं_ और _मौजूदा उपयोग_ को _ पूरे पारिस्थितिकी तंत्र _ में दोहराते हुए एक टूटे हुए रिकॉर्ड की तरह क्यों बात कर रहा हूं।

@ अगिलगुर5

और जैसा कि मैंने कई बार कहा है, इसे ओवरराइड करने के बजाय एक बहुत ही सहज ज्ञान युक्त संयोजन बना रहा है
कुछ उपयोग मामलों को असंभव बनाता है। यहाँ TSDX का उपयोग है:
https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

इस कॉन्फ़िगरेशन को आसानी से बाधित किया जा सकता है, और मुझे समझ में नहीं आता कि यह आपके लिए स्पष्ट क्यों नहीं है। मैं नहीं चाहता कि मेरी लाइब्रेरी नाजुक हो, और इसलिए मैंने यह मुद्दा बनाया है।

मजेदार बात यह है कि @ezolenko और मैंने पहले ही एक समाधान प्रस्तावित किया है जो TSDX सहित सुरक्षा में मदद करेगा, लेकिन आप अभी भी विरोध करते हैं।

डिफ़ॉल्ट केवल तभी लागू होते हैं जब आपने संपत्ति का नाम सेट नहीं किया हो

मैं डिफ़ॉल्ट व्यवहार से सहमत हूं। कॉन्फिग डिफॉल्ट को तभी लागू करना समझ में आता है जब tsconfig में संबंधित गुण न हों, लेकिन यह कई अन्य, अधिक जटिल समस्याओं को जन्म देता है, जिसका समाधान एपीआई को अधिक जटिल बना देगा।

उनके लिए डिफ़ॉल्ट को ओवरराइड करना असंभव है

प्रश्न यह है कि जिस पुस्तकालय के लेखक ने मना किया है, उस तक उपयोगकर्ता की पहुंच क्यों होनी चाहिए?

हमारे पास लीवरेज tsconfig कॉन्फ़िगरेशन होना चाहिए जिसे अधिलेखित नहीं किया जा सकता है, लेकिन साथ ही, हमें अपने प्रीसेट का विस्तार करने

समाधान केवल नए एपीआई के डिजाइन में निहित है।

इस कॉन्फ़िगरेशन को आसानी से बाधित किया जा सकता है, और मुझे समझ में नहीं आता कि यह आपके लिए स्पष्ट क्यों नहीं है। मैं नहीं चाहता कि मेरी लाइब्रेरी नाजुक हो, और इसलिए मैंने यह मुद्दा बनाया है।

तुम मेरे मुंह से ऐसे शब्द निकाल रहे हो जो मैंने दूर से नहीं कहा। मैंने यह नहीं कहा कि यह नहीं हो सकता और न ही मैंने कहा कि यह नाजुक नहीं था। मैंने अभी कहा है कि _your_ समाधान किसी भी _मौजूदा परिभाषा_ से मेल नहीं खाता है और न ही _मौजूदा उपयोग_ डिफ़ॉल्ट के _संपूर्ण पारिस्थितिकी तंत्र_ में और न ही स्वयं दस्तावेज़ों से मेल खाता है। डिफ़ॉल्ट की पूरी परिभाषा को तोड़ना स्पष्ट रूप से गलत व्यवहार है।
जैसा कि मैंने कई बार कहा है, मेरा सुझाव इसके बजाय उथले मर्ज सरणियों का था, यानी tsconfig ओवरराइड tsconfigDefaults जैसा कि यह प्रत्येक गैर-सरणी संपत्ति के लिए करता है और tsconfig _itself_ काम करता है .
जैसा कि मैंने कई बार कहा है, यह एक ब्रेकिंग चेंज या नॉन-ब्रेकिंग चेंज के साथ किया जा सकता है।

कृपया मेरे मुंह से शब्द न निकालें। मैंने खुद को कई बार दोहराया है, कृपया चीजों को बनाने के बजाय मेरे द्वारा लिखी गई वास्तविक चीजों को पढ़ें।

प्रश्न यह है कि जिस पुस्तकालय के लेखक ने मना किया है, उस तक उपयोगकर्ता की पहुंच क्यों होनी चाहिए?

tsconfig ने उसे मना नहीं किया था, TSDX ने उसे मना नहीं किया था, और rollup-plugin-typescript2 ने उसे भी मना नहीं किया था, इसलिए मुझे नहीं पता कि आप क्या कह रहे हैं।

हमारे पास लीवरेज tsconfig कॉन्फ़िगरेशन होना चाहिए जिसे अधिलेखित नहीं किया जा सकता है, लेकिन साथ ही, हमें अपने प्रीसेट का विस्तार करने

समाधान केवल नए एपीआई के डिजाइन में निहित है।

हाँ आप इसके लिए एक tsconfigConcat विकल्प जोड़ सकते हैं, और यह एक "नया एपीआई" होगा। डिफ़ॉल्ट की संपूर्ण परिभाषा का पुन: आविष्कार करके वर्तमान एपीआई को तोड़ना नई समस्याओं और नए अनपेक्षित व्यवहार का एक पूरा सेट बनाता है। सिवाय जबकि एक गहरा विलय सरणियों के लिए अनपेक्षित हो सकता है, यह अभी भी _सही_ व्यवहार है। एक संयोजन केवल गलत व्यवहार है, क्योंकि डिफ़ॉल्ट का अर्थ यह नहीं है।

एक tsconfigConcat आपके उपयोग के मामले को हल करेगा और अधिक सहज है क्योंकि इसका शाब्दिक रूप से नाम है और यह ठीक यही करता है।
tsconfigDefaults को "संयोजन" में बदलने का मतलब यह नहीं है कि यह पांचवीं बार है, डिफ़ॉल्ट का मतलब नहीं है_।

डिफ़ॉल्ट =\= संघटन। यह मेरी राय नहीं है, यही परिभाषा है।

@ agilgur5 क्षमा करें, लेकिन आपको गंभीरता से नहीं लिया जा सकता।
आपका हर वाक्य विवादास्पद है, मैं इससे थक गया हूं।

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

वैसे मैंने लोगों के मुंह से शब्द नहीं निकाले, उनके वास्तविक शब्दों को नहीं पढ़ा, चीजों को बनाया, एक योगदानकर्ता के चरित्र पर हमला किया, 0 लिंक प्रदान किए, 0 विकल्प दिए, और केवल एक ही विकल्प पर विचार किया और कोई अन्य नहीं, वह आप थे .

यदि आप किसी ऐसे योगदानकर्ता पर हमला करना चाहते हैं जो सिर्फ मददगार बनने की कोशिश कर रहा है और वास्तविक परिभाषाएं, वास्तविक उपयोग-मामले और वास्तविक विकल्प दे रहा है, तो मुझे लगता है कि यह आपका सम्मानजनक है: श्रग:

मुझे लगता है कि मैं इस धारणा के तहत था कि जब मैं उस हिस्से को लिख रहा था तो लॉश विलय वास्तव में सरणी विलय कर देगा (उन्हें या कुछ इंटरलीव करें)। या मैं इस बात पर भी ध्यान नहीं दे रहा था कि सरणियों का क्या होता है। चूंकि यह स्पष्ट रूप से तत्वों के नाम के रूप में इंडेक्स का उपयोग करके सरणी की सामग्री को ओवरराइट करता है (दाएं?

आदर्श रूप से, डिफ़ॉल्ट/मुख्य/ओवरराइड tsconfigs विकल्पों को सभी मापदंडों के अनुकूलन के लिए अनुमति देनी चाहिए, दोनों स्केलर मान और सरणियाँ, एक ही आश्चर्यजनक तरीके से। अनुक्रमणिका के आधार पर सरणी तत्वों को बदलने के लॉडश तरीके में एक बड़ी खामी है - आप शाब्दिक विरल सरणियाँ नहीं बना सकते हैं (शायद undefined s के गुच्छा के साथ पैडिंग सरणी?) इसका मतलब है कि रोलअप कॉन्फ़िगरेशन को गतिशील रूप से बनाया जाना चाहिए, और tsconfig, एक json फ़ाइल होने के नाते, उन्हें बिल्कुल भी नहीं कर सकता है।

यहां तक ​​​​कि शाब्दिक विरल सरणियों के साथ, सूचकांक के आधार पर तत्वों को बदलना बहुत नाजुक है।

दूसरी ओर, अगर कुछ और आमतौर पर इस तरह से व्यवहार नहीं करता है, तो यह आश्चर्यजनक है। और अकेले पिछले मूल्यों को हटाने की अनुमति नहीं देता है।

जैसा कि मैंने मूल रूप से प्रस्तावित किया था, संयोजन और प्रतिस्थापन के बीच स्विच करना दोगुना आश्चर्यजनक है।

सरणी थोक को बदलने के लिए दोनों विलय को बदलना @ agilgur5 प्रस्तावित शायद कम से कम आश्चर्यजनक विकल्प है, यह उन मूल्यों को दोहराने की कीमत पर मूल्यों को हटाने की अनुमति देगा, जिन्हें कोई रखना चाहता है। हालांकि यह अभी भी एक ब्रेकिंग बदलाव है और लोगों को इसके लिए अपने कॉन्फिग को फिर से लिखना होगा (देखें https://xkcd.com/1172/)।

हम या तो उन विकल्पों के व्यवहार को बदल सकते हैं या एक नया सेट बना सकते हैं और चेतावनी के साथ मौजूदा विकल्पों को हटा सकते हैं।

(क्षमा करें अगर मैं कहीं एक महत्वपूर्ण बिंदु चूक गया, तो मैंने केवल पूरे धागे को छोड़ दिया)

@ezolenko मैं अगला रास्ता

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

यह हमें क्या बताता है? आइए शब्दार्थ से शुरू करें:

जैसा कि मैंने पहले कहा था

मैं डिफ़ॉल्ट व्यवहार से सहमत हूं। कॉन्फिग डिफॉल्ट को तभी लागू करना समझ में आता है जब tsconfig में संबंधित गुण न हों ...

हम इस चीज़ को पूरी तरह से नया स्वरूप दे सकते हैं।

मेरे सुझाव हैं:

1. मूल tsconfig में संगत गुण न होने पर tsconfigDefaults गुण लागू करें।
2. tsconfigOverride को इसका ध्यान रखना चाहिए।
   2.1 इसे पहले की तरह अदिश मानों के साथ काम करना चाहिए।
   २.२ इसे सरणी गुणों को जोड़ना चाहिए। (शायद यह कुछ भी नहीं तोड़ना चाहिए और कॉन्फ़िगरेशन प्रेरणा को पूरा करना चाहिए)

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

@ agilgur5 यह आश्चर्यजनक है कि वास्तविकता और आपके द्वारा कहे गए शब्द एक ही चीज़ नहीं हैं।

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

• 0 लिंक्स - मैंने समस्या को समझने, उसका पूरी तरह से वर्णन करने, उदाहरण देने और यहां तक ​​कि स्क्रीनशॉट लेने में बहुत समय बिताया। और साथ ही, मैंने आपके TSDX का भी अध्ययन किया, और आपको बताया कि आपका कॉन्फ़िगरेशन नाजुक है, क्योंकि मैंने इसे चेक किया है। और सबसे महत्वपूर्ण बात, मैं चुप नहीं रहा, बल्कि उन लोगों के लिए समस्या को बढ़ाने के लिए इस मुद्दे को बनाया है जो इसका सामना कर रहे हैं।
• 0 विकल्प - कृपया ध्यान से पढ़ें। मैंने पहले संदेश से समाधान पेश करना शुरू किया।
• शब्दों को बाहर निकालना - शांत हो जाओ और कम से कम इस धागे में संकीर्णतावादी होना बंद करो, मेरे लिए इस तरह काम करना अप्रिय है।

@maktarsis आपके दृष्टिकोण में देव tsconfig से प्रविष्टियों को शामिल या बहिष्कृत करने में कैसे सक्षम होंगे? परिदृश्य यह है: आपके पास एक tsconfig.json है जिसका उपयोग कहीं और किया जाता है, आप इसे रोलअप में उपयोग करना चाहते हैं बिना जोंस को छुए, लेकिन आप किसी कारण से बहिष्कृत सरणी से एक पंक्ति को हटाना चाहते हैं।

@ezolenko मैं हालांकि आपकी समझ में आया।

स्वाभाविक रूप से, जैसा कि ऊपर चर्चा की गई है, यह संभव नहीं होगा।
लेकिन हम प्रेरणा के बजाय संभावनाओं की बात कर रहे हैं।

मुझे अभी भी ऐसी स्थितियाँ नहीं दिखती हैं जब हमें बहिष्कृत को फिर से लिखने की आवश्यकता होती है।
फिर भी, मेरी राय है कि हमें देव के "बहिष्कृत" को अधिलेखित करने की आवश्यकता नहीं है। दूसरे शब्दों में, मैं कल्पना नहीं कर सकता कि क्यों।
"किसी कारण से" के कारण को समझना आवश्यक है।

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

हमें दोनों की जरूरत है, सरणी में कुछ जोड़ना जो वहां नहीं है और उसमें से कुछ हटा रहा है। उथले विलय के साथ उच्च स्तर पर पूरे सरणी (परिवर्तनों के साथ) की नकल करके जोड़ना और हटाना दोनों किया जाता है। बहुत सुविधाजनक नहीं है, लेकिन प्रयोग करने योग्य है।

यह "esModuleInterop": true के मामले में भी है जिसने मेरी लाइब्रेरी को कुछ वातावरणों पर काम नहीं करने दिया।

config.json में बेकार संकलक विकल्प:

{
   ...
  "compilerOptions": {
       ...
      "esModuleInterop": true,
  },
}

रोलअप-कॉन्फ़िगरेशन में उपयोगी कंपाइलर विकल्प:

typescript({
    useTsconfigDeclarationDir: true,
    tsconfigOverride: {
      esModuleInterop: true,
    },
  }),

@maktarsis पहला सुझाव मेरे लिए अपेक्षित व्यवहार था:

tsconfigDefaults गुण लागू करें जब मूल tsconfig में संबंधित गुण न हों।

^उपरोक्त टिप्पणी असंबंधित लगती है क्योंकि यह include या सरणियों के लिए नहीं है। उल्लिखित "सुझाव" वही है जो tsconfigDefaults पहले से ही करता है।
इसके अलावा, मैं और टीएसडीएक्स, esModuleInterop भारी उपयोग करते हैं, इसलिए मुझे पता है कि यह tsconfig.json में काम करता है, यह सुनिश्चित नहीं है कि उस टिप्पणी का क्या अर्थ था। पोस्ट किया गया कॉन्फ़िगरेशन भी गायब है compilerOptions , यह होना चाहिए:

js typescript({ useTsconfigDeclarationDir: true, tsconfigOverride: { compilerOptions: { esModuleInterop: true, }, }, }),

लेकिन वह ओवरराइड करेगा और इरादा के अनुसार काम करेगा।

यहां यह ध्यान में रखते हुए कि इस रेपो में पहले कई बार उथले विलय का उल्लेख किया गया है: # 86 (जिसमें टीएस के उथले विलय व्यवहार का उल्लेख है जैसा मैंने यहां किया था), https://github.com/ezolenko/rollup-plugin-typescript2/issues/72 #इश्यूकमेंट -383242460, और https://github.com/ezolenko/rollup-plugin-typescript2/issues/208#issuecomment -594237841