Less.js: تعديل الفارس لا يتم تمريرها

أفترض أن هذا هو نفس الشيء كما في # 2772 - انظر منتصف المناقشة هناك (على سبيل المثال ، g. modifyVars له تأثيره في تحديد المتغير ، لكنه يأتي بعد أن يتم تقييم بيان الفائدة بالفعل ). ولكن انظر أيضًا https://github.com/less/less.js/issues/1400#issuecomment -137128461.

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

شكرا على الرد. يتم تحديث المتغير في عدد أقل من الملفات التي يتم استيرادها مباشرة بواسطة JS ، إنها مجرد ملفات يتم استيرادها بواسطة ملفات أقل أخرى لم يتم تحديث متغيرها. التقييم الكسول يحدث في كلتا الحالتين بالتأكيد؟ يبدو أن تعديل var logic / config لا يتم تطبيقه / تمريره إلى الملفات الأقل استيرادًا. أم هل فاتني شيء؟

يتم تحديث المتغير في عدد أقل من الملفات التي يتم استيرادها مباشرة بواسطة JS ، إنها مجرد ملفات يتم استيرادها بواسطة ملفات أقل أخرى لم يتم تحديث متغيرها.

حسنًا ، الأمر أكثر صعوبة من ذلك. لاحظ أنه لكي يعمل التقييم البطيء ، يجب على المترجم تقييم الكيانات اللغوية المختلفة (في نفس النطاق) حسب الأنواع وليس بالترتيب الذي تظهر به في الكود ، من المستوى الأعلى إلى المستوى الأدنى ، أي (تقريبًا): الاستيراد -> الخلطات - > المتغيرات.
الآن إذا كان لديك <strong i="9">@import</strong> "@{var}"; ، فإن المترجم مجبرًا على تقييم المتغير المحدد قبل الاستيراد (وجميع عمليات الاستيراد اللاحقة) - وهذا ما يفسد الأمر برمته (بشكل عام ، تكون نتيجة إساءة الاستخدام هذه غير محددة - إنها يعمل في حالة واحدة (في الغالب بسيطة جدًا) ولا يعمل في حالات أخرى).

لا توجد طريقة للمترجم لضمان أي سلوك ثابت عند دمج ميزتين متعارضتين بشكل مباشر.

بعبارة أخرى ، لا يعني ذلك أن modifyVars لا يقوم "بتحديث المتغيرات" في عمليات الاستيراد اللاحقة ، لكن قيم المتغيرات المحدثة نفسها لا يمكن أن يكون لها أي تأثير على استيراد المستوى الخارجي (لأن عمليات الاستيراد هذه "تم" بالفعل).

وحتى إذا قال المستندات:

لاحظ أنه قبل الإصدار 2.0.0 ، تم النظر فقط في المتغيرات التي تم التصريح عنها في الجذر أو النطاق الحالي وأنه تم النظر فقط في الملف الحالي وملفات الاستدعاء عند البحث عن متغير.

... إنه ليس أفضل كثيرًا بعد الإصدار الثاني. لقد حسنت / تم إصلاح المزيد من المجموعات / حالات الاستخدام ولكن لا يمكنها إصلاحها جميعًا. لمزيد من التفاصيل انظر # 1108 وتحديدا # 2246.

يبدو أن تعديل var logic / config لا يتم تطبيقه / تمريره إلى الملفات الأقل استيرادًا.

لا (ببساطة لأنه في النهاية يتم تقييم الملفات معًا كسلسلة واحدة كبيرة). ما لم تكن المشكلة في مكان آخر ، للتحقق ببساطة ، أضف:
foo {bar: @theme-variant}
لملفات الفائدة وانظر النتيجة.

على فكرة. بالنسبة لحالة الاستخدام الخاصة بك (إذا كان "* -theme.less" يتعلق فقط بالمتغيرات / الخلطات لموضوع معين) ، يمكنك تجربة شيء مثل:

• اترك القيمة الافتراضية <strong i="7">@import</strong> "a-theme.less"; لتكون مصاريف هناك (أي بدون أي استيفاء) أو قم بإزالتها تمامًا.
• باستخدام modifyVars ، اضبط بيان الاستيراد نفسه (على سبيل المثال ، <strong i="11">@import</strong> "custom-theme.less"; مباشرة).

لاحظ أنه بينما يتظاهر modifyVars بأن الأمر يتعلق فقط بالمتغيرات bla-bla-bla - في الواقع لا يفعل شيئًا سوى إلحاق نص عشوائي بنهاية الملف الجذر. أي في حالة lessc فهو في الحقيقة --modify-vars="whatever-less-code foo {bar: baz;}" . لا أعرف على الرغم من التنسيقات التي يمكن أن يمر بها محمل webpack الأقل ، حسنًا ... ربما lessOptions.modifyVars = "an arbitrary code"; ؟

من الواضح أن هذا اختراق ولكنه في الواقع يمكن التنبؤ به تمامًا (لأنه يسيء فقط تنسيق modifyVars وليس اللغة نفسها كما يفعل التحرير والسرد الأولي).

شكرًا جزيلاً على ردودكم وأفكاركم @ Seven-stage-max سأقوم بإجراء مزيد من التحقيق خلال الأسبوع وقمت بتعيين تذكير لتحديث / إغلاق هذه المشكلة في وقت لاحق من الأسبوع. شكرا لك مرة أخرى.

سأغلق هذا بعد ذلك لأنه يشبه إلى حد كبير سلوكًا متوقعًا (يُعرَّف على أنه "غير محدد / غير محدد" في هذه الحالة) بدلاً من مشكلة يمكن إصلاحها بالفعل بطريقة ما.
على الرغم من أن أي أفكار للتحسين وخاصة العلاقات العامة هي موضع ترحيب دائمًا ... لا أعتقد أن أي شخص سوف يدخل في هذا في المستقبل المنظور.