Rollup-plugin-typescript2: تم تجاوز خيار tsconfig الافتراضي "include" بواسطة الفهرس من الملف الأصلي tsconfig.json

هذا يجعل استخدام include مستحيلًا لأنك لا تعرف أبدًا كم من الوقت ستستمر المصفوفة في tsconfig.json

شيء مثير للاهتمام ،
إذا قمت بنقل الخيار typescript2 config include من tsconfigDefaults إلى tsconfigOverride
سيتم تجاوز الخيار الأصلي tsconfig.json include حسب الفهرس.

هذا هو بالضبط عكس ذلك
لكنها أيضًا سيئة جدًا

وهناك شيئ اخر
بعد بعض التحقيقات الإضافية
أدركت أن نفس السلوك مناسب لخصائص مصفوفة أخرى أيضًا

لقد واجهت هذه المشكلة من قبل في https://github.com/jaredpalmer/tsdx/pull/666#discussion_r404847759 ، وفيما يتعلق بهذه المشكلة ، هذه هي الطريقة التي يعمل بها الدمج العميق _.merge . إنه دمج عميق لذا فهو يدمج المصفوفات والفهرس هو المعرف الوحيد للمصفوفة. قد يكون الأمر _ غير متوقع_ ولكنه دمج عميق ، وهذه هي الطريقة التي تعمل بها عمليات الدمج العميقة.

في الواقع ، لا يربط هذه الخصائص ، ولكنه يستبدل القيم الموجودة في خلية الفهرس ،

• بدلاً من ذلك ، لن يتم دمج إجراء إلحاق / concat على الإطلاق ، ولن يفسح المجال للكتابة بـ tsconfig على الإطلاق. يبدو أن هذا سلوك خاطئ بالنسبة لي.
• بدلاً من ذلك ، سيؤدي إجراء دمج ضحل إلى الكتابة فوق ما هو موجود في الإعدادات الافتراضية ، والذي لست متأكدًا من أنه سلوك متوقع أيضًا ، ولكنه مشابه لكيفية عمل tsconfig فيما يتعلق بـ exclude : إذا أضفت exclude ، يقوم بالكتابة فوق الإعدادات الافتراضية.

يمكنني كتابة علاقات عامة لإجراء عملية دمج ضحلة على include و exclude ، لكن هذا سيكون _ جميل_ كسر للتغيير ؛ ليس لدي أي فكرة عن كيفية تأثير ذلك على جميع مستخدمي المصب. Idk إذا كان مستخدمو TSDX يتوقعون دمجًا ضحلًا أو عميقًا ، لكنه قد يكسر استخدامهم إذا كانوا يتوقعون عمقًا.

إذا قمت بنقل الخيار typescript2 config include من tsconfigDefaults إلى tsconfigOverride
سيتم تجاوز الخيار الأصلي tsconfig.json include حسب الفهرس.

هذا هو بالضبط عكس ذلك

نعم ، هذه هي الطريقة التي من المفترض أن يعمل بها tsconfigOverride ، إنه تجاوز.

أدركت أن نفس السلوك مناسب لخصائص مصفوفة أخرى أيضًا

نعم ، هذه هي الطريقة التي يقوم بها _.merge بدمج عميق ، لذا فإن أي شيء في tsconfig يكون مصفوفة له نفس التغيير.

@ agilgur5 شكرا على الاستجابة!

1) من وجهة نظري ، هذا السلوك يجعل التكوين عديم الفائدة تمامًا. لا يمكننا ضمان موثوقية التكوين إذا كنا مقيدين بموضع في المصفوفة.

2) في الواقع ، سيكون تغييرًا مفاجئًا. ولكن إذا كان اتجاهنا هو تحقيق أفضل DX ، فعلينا أن نجعل هذا الشيء واضحًا ومفيدًا.

لدي خدعة في جيبي للتعامل مع هذا الشيء ، لكنه يبدو صاخبًا من منظور الكود النظيف - فقط اقرأ tsconfig ، واحصل على خاصية include وقم بربطها بمصفوفي. يبدو أنه يجب أن يكون أسهل.

اقتراحي:
1) افتراضيًا - اجمع الخاصية الافتراضية وسلسلها باستخدام tsconfig الأصلي ؛ إزالة التكرارات.
2) للتجاوز - تطبيق خيار التجاوز فقط

لا تتسلسل الإعدادات الافتراضية عادةً عند تجاوزها ، بل يتم تجاوزها. وكما ذكرت أعلاه ، فإن التسلسل يجعل من _من المستحيل_ تجاوز الافتراضي بـ tsconfig . يبدو هذا سلوكًا خاطئًا بالنسبة لي من نواحٍ متعددة ، لذا فأنا لا أشجع ذلك بشدة.

أعتقد أن جميع الخيارات محيرة ، ولست متأكدًا من أنني أوافق على أن أيًا منها هو "أفضل DX". الدمج الضحل هو أقرب شيء لكيفية عمل tsconfig مع قيمته الافتراضية exclude ، لكن هذا لا يأتي بدون مقايضات.
بشكل عام ، يجب التفكير في تغيير التغييرات بشكل كبير ، وهذا هو السبب في أنني طرحت هذا الأمر - فإن التأثيرات النهائية غير تافهة ؛ سيتعين على TSDX أيضًا إصدار تغيير فاصل لتحديث هذا التغيير.

@ agilgur5 جيد ، إذًا لا يمكنني استخدام
سبب؟ ليس هناك ما يضمن عدم كتابة أي قيمة في هذا الفهرس.
بالإضافة إلى ذلك ، يمكنك الالتفاف حول كل شيء من خلال القيمة غير المحددة كقيمة للمصفوفة ، وإضافة القيمة التي تريدها بشكل أكبر. واتضح أن هناك فجوة في هذا النظام؟ رائعا.

القضية:

1. أريد إضافة كتاباتي d.ts الإضافية داخل خاصية التهيئة "include".
2. يقوم المستخدم بوضع src dir داخل "include" مع مشروع آخر محدد للكتابة d.ts خارج src .

1. ['config.d.ts`]
   2. ['src'، 'some.d.ts'، 'other.d.ts']
2. النتيجة: ['src'، 'some.d.ts'، 'another.d.ts']

كما ترى ، لا توجد طريقة لتكوين هذا بشكل صحيح. يجب أن أقرأ tsconfig.json ، وأحصل على خاصية "include" ودمجها في ['src'، 'some.d.ts'، 'another.d.ts'، 'config.d.ts'].
وأعتقد أن هذا هو عبء كامل.

في غضون ذلك ، اكتشفت ما هي المشكلة. قد لا يكتشف الآخرون الأمر ويقضون وقتهم الثمين لمعرفة ما لا يصلح لهم.
وبعد رسالتك الأولى ، رأيت بالفعل مشكلتين مرتبطتين على الأقل. وسوف تستمر وتطول.

أرى أنه إذا تركنا كل شيء كما هو ، فعندئذ لا يمكنني استخدامه ، إنه صندوق أسود بالنسبة لي لأنني لا أستطيع ضمان أي شيء.
لا يوجد مكان للتفضيلات الشخصية "أعجبني" / "لم يعجبني".
يمكن استخدام هذا أم لا. ولا يمكن.

ليس لدي مشكلة في جمع آراء الآخرين الذين يشاركون في ذلك.
وشيء آخر ، ليس لدي أي مشاكل للبقاء مع الحل الحالي ، لدي الاختراق الموصوف أعلاه ، والذي أنا مستعد للالتزام به. لكني لا أفهم ما هي المشكلة في جعل هذا الحل شفافًا ، دون التقيد بحقيقة أنه سيترتب عليه تغييرات جذرية.

أعني ، أنت تعطي تفضيلاتك الخاصة هنا بينما أعطيت العديد من الخيارات المختلفة بالفعل. لقد قلت مرتين من قبل لماذا يتم كسر هذا التفضيل ، التسلسل ، بشكل أساسي ، وغير بديهي بالمثل ، وغير "شفاف" على الإطلاق. للتكرار ، فإن التسلسل ليس _فقط_ تغييرًا فاصلًا ، فهو حرفيًا يجعل تجاوز الأشياء أمرًا مستحيلًا . سأكرر مرة أخرى ، مستحيل .
استحالة تجاوز التسلسل ليس "تفضيلًا" ، هذه حقيقة.

مرة أخرى ، "الافتراضي" الذي لا يمكن تجاوزه ليس افتراضيًا ، وهذا مطلب. تغيير "افتراضي" إلى متطلب لا معنى له وهو سلوك خاطئ.

يمكنك تجاوز الدمج العميق في الوقت الحالي ، ولا يمكنك تجاوز سلسلة. جعل حالة الاستخدام الحالية مستحيلة لا معنى له.

لقد قدمت بالفعل خيارًا بديلاً مرتين بالفعل لم يتم كسره بشكل أساسي ، وهو دمج ضحل. سأكرر مرة أخرى ، يمكنك استخدام دمج ضحل لحل هذا أيضًا.
سواء كان ذلك أفضل هو أمر قابل للنقاش. هناك مقايضات لكل شيء.

لقد ساهمت هنا في إصلاح الأخطاء من قبل (أعرف أنها _.merge لأنني قرأت التعليمات البرمجية) والمكتبة التي أحافظ عليها تشكل جزءًا كبيرًا من استخدام هذه المكتبة (~ 10٪) ، أنا ليس فقط وضع نقاط للحديث هنا ...

ناهيك عن أنه يمكن حل هذا دون تغيير التغييرات - يمكنك إضافة خيار جديد مقابل tsconfigConcat أو tsconfigDefaultShallow إلخ.

إن القول بأن هناك خيارًا واحدًا فقط ويجب كسره ويجب أن يجعل حالة الاستخدام الحالية مستحيلة هو ببساطة ليس صحيحًا.

أعتقد أنه سيتعين علينا كسر الأشياء بغض النظر عما نفعله هنا. لجعلها تتصرف وفقًا لروح التوثيق وأسماء الممتلكات ، يجب أن تفعل ما يلي في الأساس:

• tsconfigDefaults - هذا هو الكائن الذي سيتم دمج كل شيء أدناه فيه بعمق
• tsconfig - هذا هو الشيء الذي نحصل عليه من الكتابة المطبوعة ، بعد عمليات الاستيراد الخاصة به وكل شيء. تحل جميع القيم هنا محل القيم الموجودة في tsconfigDefaults . جميع المصفوفات هنا متسلسلة بمصفوفات في tsconfigDefaults .
• tsconfigOverride - هذا هو الخيار النووي. لا تزال الكائنات مدمجة بعمق ، لكن المصفوفات هنا تحل محل المصفوفات بالجملة. لذلك إذا قمت بتوفير مصفوفة تضمين فارغة هنا ، فلن يكون لـ tsconfig النهائي أي تضمين على الإطلاق.

هل سيغطي ذلك جميع الحالات التي نريد دعمها (بعد قيام المستخدمين بإجراء التغييرات المناسبة) ، أو هل فاتني شيء ما؟

يبدو ezolenko مذهلاً ومن المنطقي استخدامه كثيرًا

ezolenko لست متأكدا لماذا يجب عليك كسر الأشياء؟ لقد قدمت خيارات غير قابلة للكسر بالفعل.

لست متأكدًا من أن ما أدرجته يعكس "روح التوثيق وأسماء الممتلكات" لأن المستندات تقول:

الكائن الذي تم تمريره كـ tsconfigDefaults سيتم دمجه مع تحميل tsconfig.json . سيكون التكوين النهائي الذي تم تمريره إلى الكتابة المطبوعة هو نتيجة القيم الموجودة في tsconfigDefaults التي تم استبدالها بالقيم المحملة tsconfig.json
[...]
هذا دمج عميق (يتم دمج الكائنات ، يتم تجميع المصفوفات ، يتم استبدال العناصر الأولية ، إلخ) ، قم بزيادة verbosity إلى 3 وابحث عن parsed tsconfig إذا حصلت على شيء غير متوقع.

تقول "مدمجة" و "استبدلت" و "دمج عميق" ، وكلها تعني استبدال وتجاوز الافتراضي. هناك إشارة واحدة إلى "متسلسلة" تختلف عن البقية ، ولكن الدمج العميق لا _ لا _ في الواقع متسلسلًا. 5 مراجع تقول شيئًا واحدًا والسادس غير صحيح. بالنسبة لي ، هذا يبدو وكأنه يجب تصحيح المرجع السادس غير الصحيح ، وليس المراجع الخمسة الصحيحة التي تم تغييرها إلى السادس غير الصحيح.

lodash هو المعيار الفعلي وتعريفه للدمج هو _لا_ للتسلسل. تعريف الافتراضيات أنه يتم تجاوزها عند تعيين نفس قيمة الخاصية ، _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 .

لذا فإن التسلسل لا يتطابق مع أكثر من 5 مراجع في المستندات بالفعل ، أو تعريف الدمج ، أو تعريف الإعدادات الافتراضية ، أو سلوك tsconfig الخاص. ويكسر التماثل ومستندات الخيارات الأخرى. لست متأكدًا من أن هذا أمر بديهي.

وكما قلت عدة مرات ، فإن جعله تسلسلًا غير بديهي للغاية بدلاً من _ غير ممكنة_ . هنا هو استخدام TSDX:

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

الهدف هو أنك إذا أضفت exclude الخاص بك ، فإنه يتجاوز الإعدادات الافتراضية التي قمنا بتعيينها. يتم تطبيق الإعدادات الافتراضية فقط إذا لم تقم بتعيين اسم الخاصية ، تمامًا مثل كل اسم خاصية آخر (مرة أخرى ، هذا هو تعريف الإعدادات الافتراضية وكيفية عمل الإعدادات الافتراضية في جميع المكتبات).

إذا كنت تريد تغيير ذلك إلى التسلسل ، فلن يكون لدى المستخدم الآن أي طريقة لتجاوز الافتراضي exclude ، فمن _ من الممكن_ بالنسبة لهم تجاوز tsconfig الافتراضي exclude ، لذلك يجعل هذا أيضًا من _ من الممكن الإعداد الافتراضي tsconfig ، على الرغم من أن tsconfig _itself_ يتيح لك القيام بذلك الذي - التي.

لست متأكدًا من سبب حديثي كسجل مكسور هنا مكررًا _التعريفات الحالية _ والاستخدام الحالي _ في _ النظام البيئي بأكمله _.

@ agilgur5

وكما قلت عدة مرات ، مما يجعلها سلسلة غير بديهية للغاية بدلاً من تجاوزها
يجعل حالات استخدامات معينة مستحيلة. هنا هو استخدام TSDX:
https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

يمكن تعطيل هذا التكوين بسهولة ، ولا أفهم سبب عدم وضوح ذلك بالنسبة لك. لا أريد أن تكون مكتبتي هشة ، ولهذا السبب صنعت هذه المشكلة.

الشيء المضحك هو أن ezolenko وأنا قد اقترحنا بالفعل حلاً يساعد في الحماية ، بما في ذلك TSDX ، لكنك ما زلت تقاوم.

يتم تطبيق الإعدادات الافتراضية فقط إذا لم تقم بتعيين اسم الخاصية

أنا أتفق مع السلوك الافتراضي . من المنطقي تطبيق الإعداد الافتراضي للتكوين فقط عندما لا يكون لـ tsconfig خصائص مقابلة ، ولكن هذا يؤدي إلى العديد من المشكلات الأخرى الأكثر تعقيدًا ، والتي سيؤدي حلها إلى تعقيد واجهة برمجة التطبيقات.

من المستحيل بالنسبة لهم تجاوز الافتراضي

السؤال هو ، لماذا يجب أن يكون للمستخدم حق الوصول إلى ما نهى عنه مؤلف المكتبة؟

يجب أن يكون لدينا تكوين tsconfig ذي نفوذ لا يمكن الكتابة فوقه ، ولكن في نفس الوقت ، نحتاج إلى إعطاء الفرصة لتوسيع إعداداتنا المسبقة. وهذه هي النقطة الرئيسية.

يكمن الحل فقط في تصميم واجهة برمجة التطبيقات الجديدة.

يمكن تعطيل هذا التكوين بسهولة ، ولا أفهم سبب عدم وضوح ذلك بالنسبة لك. لا أريد أن تكون مكتبتي هشة ، ولهذا السبب صنعت هذه المشكلة.

أنت تأخذ كلمات من فمي لم أقلها عن بعد. لم أقل أنه لا يمكن ولم أقل أنه لم يكن هشًا. لقد قلت للتو إن الحل الخاص بك لا يتطابق مع أي _ تعريف حالي_ ولا _ استخدام حالي _ في النظام البيئي بأكمله للقياسات الافتراضية ولا في المستندات نفسها. من الواضح أن كسر تعريف التخلف عن السداد بالكامل هو سلوك خاطئ.
كما قلت عدة مرات ، كان اقتراحي هو دمج المصفوفات الضحلة بدلاً من ذلك ، على سبيل المثال ، يتجاوز tsconfig tsconfigDefaults كما هو الحال مع كل خاصية غير مصفوفة وكما هو الحال مع tsconfig _itself_ .
كما قلت عدة مرات ، يمكن القيام بذلك بتغيير جذري أو تغيير غير منقطع.

من فضلك لا تأخذ الكلمات من فمي. كررت نفسي عدة مرات ، يرجى قراءة الأشياء الفعلية التي كتبتها بدلاً من اختلاق الأشياء.

السؤال هو ، لماذا يجب أن يكون للمستخدم حق الوصول إلى ما نهى عنه مؤلف المكتبة؟

tsconfig لم يمنع ذلك ، TSDX لم يمنع ذلك ، و rollup-plugin-typescript2 لم يمنع ذلك أيضًا ، لذلك لا أعرف ما الذي تشير إليه.

يجب أن يكون لدينا تكوين tsconfig ذي نفوذ لا يمكن الكتابة فوقه ، ولكن في نفس الوقت ، نحتاج إلى إعطاء الفرصة لتوسيع إعداداتنا المسبقة. وهذه هي النقطة الرئيسية.

يكمن الحل فقط في تصميم واجهة برمجة التطبيقات الجديدة.

نعم ، يمكنك إضافة خيار tsconfigConcat لهذا ، وسيكون ذلك "واجهة برمجة تطبيقات جديدة". يؤدي كسر واجهة برمجة التطبيقات الحالية عن طريق إعادة اختراع التعريف الافتراضي بالكامل إلى إنشاء مجموعة كاملة من المشكلات الجديدة والسلوك الجديد غير البديهي. باستثناء أنه بينما قد يكون الدمج العميق غير بديهي للمصفوفات ، فإنه لا يزال سلوكًا صحيحًا. التسلسل هو ببساطة سلوك خاطئ ، لأن هذا ليس ما يعنيه الافتراضي.

ستحل tsconfigConcat A
تغيير tsconfigDefaults ليعني "concatenation" ليس لأن هذا ، للمرة الخامسة ، _ليس ما يعنيه الافتراضي_.

الافتراضي = \ = التسلسل. هذا ليس رأيي ، هذا هو التعريف.

@ agilgur5 آسف ، لكن لا يمكن أن تؤخذ على محمل الجد.
كل جملة لديك مثيرة للجدل ، لقد سئمت منها.

أنا أزعم ببساطة أن واجهة برمجة التطبيقات الحالية لا تسمح بأي عمل مناسب معها على الإطلاق ، وهذا هو سبب تغييرها.
لن أواصل هذا بعد الآن.

حسنًا ، لم أخرج الكلمات من أفواه الناس ، ولم أقرأ كلماتهم الفعلية ، أو اختلق الأشياء ، أو هاجم شخصية المساهم ، وأقدم 0 رابطًا ، وأعطي 0 بدائل ، وفكر فقط في خيار واحد دون غيره ، كان هذا أنت .

إذا كنت ترغب في مهاجمة أحد المساهمين الذي يحاول فقط أن يكون مفيدًا ويقدم تعريفات حقيقية ، وحالات استخدام حقيقية ، وبدائل حقيقية ، فأعتقد أن هذا من اختصاصك: تجاهل:

أعتقد أنني كان لدي انطباع بأن دمج اللوداش من شأنه في الواقع دمج المصفوفات (تشذيرهم أو شيء من هذا القبيل) عندما كنت أكتب هذا الجزء. أو لم أكن أهتم بما يحدث للمصفوفات. نظرًا لأنه يبدو أنه يقوم بالكتابة فوق محتويات المصفوفات باستخدام الفهارس كأسماء عناصر (أليس كذلك؟ هل هذا الشيء في جافا سكريبت حول المصفوفات ليس في الأصل مصفوفات حقيقية ، ولكن بدلاً من ذلك هو قواميس تصادف وجود أرقام للمفاتيح؟) ، تكمن وثائقنا في الوقت الحالي.

من الناحية المثالية ، يجب أن تسمح خيارات tsconfigs الافتراضية / main / override بتخصيص جميع المعلمات ، سواء القيم العددية أو المصفوفات ، بنفس الطريقة غير المفاجئة. طريقة Lodash لاستبدال عناصر المصفوفة استنادًا إلى الفهرس لها عيب رئيسي واحد - لا يمكنك إنشاء مصفوفات متفرقة حرفية (ربما صفيف حشو بمجموعة من undefined s؟). هذا يعني أنه يجب بناء تكوين الالتقاط بشكل ديناميكي ، ولا يمكن لـ tsconfig ، كونه ملف json ، القيام بها على الإطلاق.

حتى مع المصفوفات المتناثرة الحرفية ، فإن استبدال العناصر بناءً على الفهرس يعد أمرًا هشًا للغاية.

من ناحية أخرى ، فإن التسلسل مثير للدهشة ، إذا لم يكن هناك شيء آخر يتصرف بهذه الطريقة عادة. وحده لا يسمح بإزالة القيم السابقة.

التبديل بين التسلسل والاستبدال كما اقترحت في الأصل أمر مثير للدهشة على نحو مضاعف.

من المحتمل أن يكون تغيير الدمجتين لاستبدال المصفوفات بالجملة كما اقترح

يمكننا إما تغيير سلوك هذه الخيارات أو إنشاء مجموعة جديدة وإهمال الخيارات الحالية مع تحذير.

(آسف إذا فاتني نقطة مهمة في مكان ما ، فقد قمت فقط بتخطي الموضوع بأكمله)

ezolenko أرى الطريقة التالية

لنلق نظرة على الموقف والدافع:
يريد المطور إضافة بعض التكوينات الضرورية للطباعة عبر البرنامج المساعد التراكمي.
في هذه الحالة ، يجب ألا نمنع المطور من إضافة الإعدادات بأمان ، ولا نفقد أي إعدادات أخرى عند دمج التكوين وتكوينات التراكمية.

ما يخبرنا هذا الكلام؟ لنبدأ من الدلالات:

كما قلت من قبل

أنا أتفق مع السلوك الافتراضي. من المنطقي تطبيق الإعداد الافتراضي فقط عندما لا يكون لـ tsconfig خصائص مقابلة ...

يمكننا إعادة تصميم هذا الشيء بالكامل.

اقتراحاتي هي:

1. تطبيق خصائص tsconfigDefaults عندما لا يكون للخاصية الأصلية tsconfig خصائص مقابلة.
2. يجب أن يتولى tsconfigOverride هذا الأمر.
   2.1 يجب أن يعمل كما كان من قبل مع القيم العددية.
   2.2 يجب أن تسلسل خصائص الصفيف. (ربما لا ينبغي أن يؤدي هذا إلى كسر أي شيء ويجب أن يلبي دافع التكوين)

أحاول فقط تجنب الخيار rpt2 الإضافي الثالث ، لأنه سيعقد واجهة برمجة التطبيقات هذه بنسبة 50٪ على الأقل وسيتوقف أي مطور عن فهم ذلك.

@ agilgur5 إنه لأمر رائع أن الحقيقة والكلمات التي تقولها ليست هي نفسها.

أيضًا ، بفضل إشعار البريد الإلكتروني ، قرأت الرسالة الأصلية ، ولم أحررها 8 مرات ، لأبدو أفضل في أعين الناس.
لا أحد يريد مهاجمتك ، علاوة على ذلك ، لم يفعلها أحد.
لقد طُلب منك ببساطة التوقف عن العدوانية والتوقف عن كتابة خطابات متناقضة في هذا الموضوع.

• 0 روابط - لقد قضيت الكثير من الوقت لفهم المشكلة ووصفها بالكامل وإعطاء أمثلة وحتى لقطات شاشة. وأيضًا ، لقد درست TSDX الخاص بك ، وأخبرتك أن التكوين الخاص بك هش ، لأنني تحققت منه. والأهم من ذلك ، أنني لم أصمت ، لكنني خلقت هذه القضية لتصعيد المشكلة لأولئك الذين يواجهونها.
• 0 بدائل - الرجاء القراءة بعناية. بدأت في تقديم الحلول من الرسالة الأولى.
• استخرج الكلمات - اهدأ وتوقف عن كونك نرجسيًا على الأقل في هذا الموضوع ، من غير السار بالنسبة لي أن أعمل بهذه الطريقة.

maktarsis كيف سيتمكن مطور البرامج من إزالة التضمين أو الاستبعاد من tsconfig من خلال أسلوبك؟ السيناريو هو: لديك tsconfig.json يتم استخدامه في مكان آخر ، وتريد استخدامه في التجميع دون لمس json نفسه ، لكنك تريد إزالة سطر من مصفوفة الاستبعاد لسبب ما.

ezolenko فهمت على الرغم من ذلك.

بطبيعة الحال ، كما نوقش أعلاه ، لن يكون هذا ممكنًا.
لكننا نتحدث عن الاحتمالات وليس الدافع.

ما زلت لا أرى مواقف نحتاج فيها إلى إعادة كتابة الاستثناء.
ومع ذلك ، فأنا أرى أننا لسنا بحاجة إلى الكتابة فوق "استبعاد" dev. بعبارة أخرى ، لا أستطيع أن أتخيل السبب.
من الضروري فهم سبب "لسبب ما".

إذا كنت ترغب في الحصول على هذا الاحتمال على أي حال ، فأنت بحاجة إلى توفير واجهة برمجة تطبيقات إضافية للتسلسل.
ولكن كما قد تفهم ، أعتقد أنه قد يكون غير مطلوب وببساطة غير ضروري.
قد لا يكون استبعاد شيء ما من "الاستبعاد" ضروريًا على الإطلاق ، ولكن إذا ذهبنا في الاتجاه الآخر ، فإننا نعقد فهم التكوين.

نحتاج إلى كليهما ، إضافة شيء ما إلى المصفوفة غير موجود وإزالة شيء منه. مع الدمج الضحل يتم إجراء كل من الإضافة والإزالة عن طريق تكرار مجموعة كاملة (مع التغييرات) على مستوى أعلى. ليست مريحة للغاية ، ولكنها قابلة للاستخدام.

هذا هو الحال أيضًا مع "esModuleInterop": true مما جعل مكتبتي لا تعمل في بعض البيئات.

خيار مترجم عديم الفائدة في config.json:

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

خيار مترجم مفيد في التكوين التراكمي:

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

كان اقتراح maktarsis الأول بالنسبة لي هو السلوك المتوقع:

قم بتطبيق خصائص tsconfigDefaults عندما لا يكون لـ tsconfig الأصلي خصائص مقابلة.

^ التعليق أعلاه يبدو غير ذي صلة لأنه ليس لـ include أو المصفوفات. "الاقتراح" المذكور هو ما يفعله tsconfigDefaults بالفعل.
أيضًا أنا و TSDX نستخدم esModuleInterop بكثافة لذا أعلم أنه يعمل في tsconfig.json ، لست متأكدًا مما كان من المفترض أن يعنيه هذا التعليق. يفتقد التكوين المنشور أيضًا compilerOptions ، يجب أن يكون:

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

لكن هذا من شأنه أن يتجاوز ويعمل على النحو المنشود.

وإذ تلاحظ هنا أن دمج الضحلة تم ذكرها سابقا في هذه الريبو عدة مرات: # 86 (الذي يذكر الضحلة دمج السلوك TS كما فعلت هنا)، https://github.com/ezolenko/rollup-plugin-typescript2/issues/72 #issuecomment -383242460 و https://github.com/ezolenko/rollup-plugin-typescript2/issues/208#issuecomment -594237841