Less.js: ES6 & تراكمي

لا. لقد كنت أفكر على نفس المنوال لفترة من الوقت. ماذا عن استخدام TypeScript؟ قد يجعل التطوير / المساهمات أسهل في الحصول على تلميحات التعليمات البرمجية / ربط كائن حقيقي. على الرغم من أنني لا أعرف ما إذا كان هذا سيضع عبئًا / حاجزًا معرفيًا بعد ذلك.

كنت أفكر أيضًا على نفس المنوال الذي يجب أن نفكر فيه في استخدام مجموعات es6 للتحليل / AST ثم استخدام polyfill لبناء es5 مثل https://github.com/Benvie/harmony-collections. في بيئات es6 (وهي Node.js الآن ، مثلها مثل أحدث المتصفحات) التي يجب أن تُسرع نظريًا من التحليل / التقييم بسبب تقليل عبء الذاكرة وبناء AST بشكل أسرع.

ماذا عن استخدام TypeScript؟ قد يجعل التطوير / المساهمات أسهل في الحصول على تلميحات التعليمات البرمجية / ربط كائن حقيقي. على الرغم من أنني لا أعرف ما إذا كان هذا سيضع عبئًا / حاجزًا معرفيًا بعد ذلك.

يمكننا أن نعتبر أنه بعد ES6 - es6 لا يستبعد الكتابة المطبوعة نظرًا لأن الكتابة المطبوعة هي عبارة عن مترجم es6 أيضًا .. ستكون خطوة إضافية بعد ذلك.

أنا شخصياً لا أوصي بالطباعة ما لم يكن هناك عمل إضافي كبير أو إعادة بناء ديون في أقل. IMO مطبعي

• + يجعل تطوير الأشخاص الجدد الذين يعرفون الكتابة المطبوعة أسهل
• + يزيد من قابلية الصيانة
• 
  
  • يتطلب أن يعرف الناس أو يتعلمون الحد الأدنى من الكتابة المطبوعة
  
  
• 
  
  • يستغرق وقتًا أطول لكتابة التعليمات البرمجية بحيث يتم كتابتها
  
  

كنت أفكر أيضًا على نفس المنوال الذي يجب أن نفكر فيه في استخدام مجموعات es6 للتحليل / AST ثم استخدام polyfill لبناء es5 مثل https://github.com/Benvie/harmony-collections. في بيئات es6 (وهي Node.js الآن ، مثلها مثل أحدث المتصفحات) التي يجب أن تُسرع نظريًا من التحليل / التقييم بسبب تقليل عبء الذاكرة وبناء AST بشكل أسرع.

لن أستخدم هذا polyfill ، يبدو المشروع ميتًا (ربما أيضًا لأن اسم الانسجام مات).

كما أنني للأسف لن أتأكد من أن مكافئات ES6 الأصلية أسرع - https://jsperf.com/property-access-object-array-map-weakmap/6. من المحزن كيف أن Promise polyfill على سبيل المثال أسرع من التنفيذ المحلي :(

: +1:

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

فيما يتعلق باختبار jsperf ، فهو ليس مثالًا عادلًا حقًا. أتوقع أن يكون أداء Weakmap أبطأ لهذا الاختبار المحدد. من الناحية النظرية ، قد يكون من الأفضل لـ Less في إنشاء مجموعة من أشكال وأنواع الكائنات المختلفة ثم تقييمها. لست متأكدا بالرغم من ذلك. لقد وجدت عددًا قليلاً من المكتبات الجيدة التي أرغب في اختبارها في النهاية (ونأمل أن أضيف) حيث يمكننا ربط الوظائف الفردية للقيام بمقارنة مرجعية محببة ، دون الحاجة إلى وضع أي "خطافات مرجعية" في lib. آمل أن أقوم بإعداد شيء ما (عندما يكون لدي وقت ، من يعرف متى سيكون ذلك) حتى تتمكن من إجراء نوع من اختبار jsperf على الوظائف داخل Less.js ، ولكن مع تغييرات التطوير / الفرع المحلي إلى Less vs. الإصدار الحالي ، واستخدام أنواع قليلة من ملفات الاختبار. كما ذكرت من قبل ، لا يجب أن نخمن أيهما أسرع لحالة الاستخدام الخاصة بنا. يمكننا نظريًا التقسيم إلى WeakMap على مستوى وظيفة ما مقابل الكائنات الخام ، وإجراء معايير على هذا الموقع ، واتخاذ القرار بناءً على النتيجة.

lukeapage كتب:
IMO مطبعي

• + يجعل تطوير الأشخاص الجدد الذين يعرفون الكتابة المطبوعة أسهل
• + يزيد من قابلية الصيانة
• 
  
  • يتطلب أن يعرف الناس أو يتعلمون الحد الأدنى من الكتابة المطبوعة
  
  
• 
  
  • يستغرق وقتًا أطول لكتابة التعليمات البرمجية بحيث يتم كتابتها
  
  

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

ربما يساهم الانتقال إلى TypeScript في أكثر من مجرد الانتقال إلى ES6 ، imho.

عن طريق الوضع المكتوب تقصد لا سمح أي؟

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

فيما يتعلق بعدد المتغيرات التي تحتوي على أنواع متغيرة متحولة ، لست متأكدًا. لذا..
غير مقتنع بأن فائدة الأداء ستكون ملحوظة.

rjgotten لم أستخدم TypeScript لكن هذه نقاط جيدة. إذا كنت تستخدم بيئة intellisense / autocomplete لـ TypeScript ، فقد تساعد بالفعل المساهمين الجدد لأنها ستكمل الأنواع / أشكال الكائنات أثناء إجراء التغييرات. تم تصميمه بشكل صحيح ، ويمكن أن يكون بمثابة نوع من أداة التوثيق الذاتي / التعرّف / منع الأخطاء لشخص يساهم في تغييرات التعليمات البرمجية. لكن المفتاح موجود على الأرجح في تصميم TypeScript.

بشكل عام ، هل سيكون هناك فائدة في الأداء؟ يصعب تحديد ذلك. هذا هو الفنان أكثر من القماش.

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

أيضًا ، لا يمنع الانتقال إلى ES6 استخدام TypeScript في المستقبل. يتمثل هدف Microsoft / Google في جعل TypeScript 2.0 مجموعة شاملة ES6 ، لذلك يمكننا دائمًا البدء بـ ES6 / Babel ، ثم نضيف لاحقًا الأنواع المناسبة والتبديل إلى محول TypeScript. أشك في أن TypeScript سوف "تربح" اللغات المترجمة ، فقط لأن مزايا وقت الترجمة / الإكمال التلقائي أكبر بكثير من JavaScript غير المكتوب. لذا ... أعتقد أن هذا يعني أنني أعتقد أن استخدام TypeScript ربما لا مفر منه ، لكن هذا لا يعني أنه يتعين علينا استخدامه على الفور.

أود أن أناقش نهجًا معماريًا مختلفًا لـ Less في وقت ما ، لكن هذا أكثر من مناقشة واضحة لهذا الأمر.

عن طريق الوضع المكتوب تقصد لا سمح أي؟

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

ومع ذلك ، فإن استخدام المعلمات المكتوبة في وظيفة ما يعني أن المتصلين (على الأقل مكتوبون بلغة TypeScript) يجب أن يحترموا النوع المعطى. وهذا يعني أنه يمكن استخدام الوظائف المكتوبة لحماية استقرار النوع في الأعمال الداخلية للمترجم الأقل حيثما كان ذلك مناسبًا وضمان تحسين الوظائف المهمة بشكل جيد. (لا تنس ؛ تعمل محركات JS بشكل عام على تحسين مستوى الوظيفة ...)

بدأ العمل - https://github.com/less/less.js/tree/rollup

عمل رائع. جيرمين للمناقشة ، كنت أنظر إلى الكود ووجدت بسرعة:

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

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

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

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

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

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

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

قد يكون هذا هو الحال ، ولكي تكون عمليًا ، فقد تولىlukeapage العمل بالفعل ، لذا فأنا أميل إلى القول إنه يجب عليه إجراء المكالمة النهائية في هذا الوقت. :-)

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

لا ، لا ينبغي أن يكون هناك الكثير من النزاعات. الخطوة الأولى هي مجرد وحدات es6 - لا
نقل أي ملفات ، ثم يمكننا إضافة بابل أو مطبوعة بشكل شفاف.

مرحبا يا رفاق ، كيف الحال الآن؟

يمكنني العمل على هذا. @ ماثيو دين هل تقبل طلب السحب؟

alexlur بالتأكيد! قلقي الوحيد هو إعادة بناء الفرع 3.x وعدم الحصول على تعارضات الدمج. لذلك من الأفضل أن تتفرع من هناك. أيضًا ، نظرًا لأنه تمت كتابة هذه المشكلة ، فهناك الآن اصطلاح راسخ الآن لاستخدام src/ و dist/ . ومع ذلك ، يتم استخدام lib/ أحيانًا كـ src/ ، لذلك ربما لا داعي لإعادة التسمية.

سيكون هناك أيضًا قدر ضئيل من إعادة كتابة Gruntfile بحيث تستخدم الاختبارات إصدارات وليس lib/ . (ما يفعله اختبار المتصفح هو إجراء إنشاء في test/ وليس dist/ . يُعد المجلد dist/ مهمة Grunt خاصة للإصدارات الجديدة. عند الاختبار ، يجب أن يُنشئ test/ ) بعد القيام بذلك ، طالما اجتازت الاختبارات ، يجب أن تكون جيدًا.

@ ماثيو دين مرحبا هناك. لقد انتهيت من إعادة البناء ولكني لا أعرف كيفية تكوين Gruntfile لتشغيل الاختبارات على الملفات المبنية الجديدة.

ربما ما يمكنني فعله هو دمج تغييراتك في فرع منفصل ومعرفة ما يتعلق بدمج الاختبارات. كنت أبحث بسرعة في التغييرات الخاصة بك. صححني إذا كنت مخطئًا ، ولكن هل العقدة at-rule بشكل غير صحيح هي العقدة assignment ؟ أم أن Github أخطأ فقط كيف كان يظهر ذلك؟

تمسك جيد ، لقد استخدمت الملف الخطأ.

هل يوجد حد أدنى من إصدار المتصفح / Node.js يجب أن يدعمه less.js؟ يتمتع Node.js بدعم جيد إلى حد ما لـ Promise (منذ 0.12) ، بينما يكون استخدام المتصفح عمومًا للمطورين الذين يقومون بالفعل بتشغيل أحدث إصدارات المتصفح على أي حال.

تعديل:

يدعم Less.js جميع المتصفحات الحديثة (الإصدارات الحديثة من Chrome و Firefox و Safari و IE11 + و Edge)

فقط Internet Explorer 11 لا يحتوي على Promise مدمج.

تضمين التغريدة
بالنسبة لإصدار Less في المتصفح ، أقترح إنشاء خاصية less.Promise ، وتعيينها على window.Promise افتراضيًا. ثم اطلب أقل من فئة الوعد من خلال less.Promise .

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

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

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

على جانب العقدة ، لا تزال هذه المشكلة مفتوحة: https://github.com/less/less.js/issues/3121

ومع ذلك ، بدون أي تعليقات ، ومع وجود عدد معتدل إلى حد ما من المساهمين ، أميل إلى القول إن Node 4+ هي الطريقة التي يجب اتباعها في الوقت الحالي. يجب علينا تحديث المستندات / الاختبارات لتعكس ذلك.

@ Matthew-dean يجب أن يكون جاهزًا للدمج في فرع منفصل .

alexlur شكرا! سأحاول إلقاء نظرة قريبا. من المحتمل أن يكون الأسبوع المقبل (ما لم يكن لدى شخص آخر فترة سماح للتحقق من ذلك).

تم وضع علامة على هذه المشكلة تلقائيًا على أنها قديمة نظرًا لعدم وجود نشاط حديث لها. سيتم إغلاقه إذا لم يحدث أي نشاط آخر. شكرا لمساهماتكم.

لقد قمت بإنشاء شوكة مُعاد تشكيلها إلى TypeScript.

لقد قمت بإنشاء شوكة مُعاد تشكيلها إلى TypeScript.

glixlur 😮 نجاح باهر ، وكل الاختبارات تمر؟ ويصنع less.js متطابقًا في dist/ ؟

@ Matthew-dean ما زلت أعمل عليه ، لكن تصميم المتصفح الخاص بي لم يواجه أي مشكلة حتى الآن كسائق يومي. من الناحية الفنية ، فإن استخدام التراكمي يمنح شوكة بلدي ميزة في الأداء ولكن ليس لدي بيانات لدعمها.

@ less / core يجب التحقق من ذلك لمعرفة ما إذا كان بإمكاننا أتمتة هذا لتحويل لمرة واحدة - https://github.com/lebab/lebab

@ ماثيو دين سأرسل لك طلب سحب بمجرد أن أنتهي.

تضمين التغريدة حسنًا ، في العلاقات العامة السابقة ، قلت إنه ليس لديك وقت لهذا. إذا كنت لا تزال تعمل على هذا ، 👍

@ Matthew-dean سأقصر نفسي على مجرد التحويل إلى ES6 وترك جزء TypeScript لاحقًا.

glixlur أعتقد أن ES6 هي على الأرجح الخطوة الأولى "الصديقة للمجتمع" للمضي قدمًا ، لذلك هذا مثالي. لست متأكدًا من أن الجميع على متن TypeScript ، ولكن بالتأكيد سيكون تدفق ES6 رائعًا.

@ Matthew-dean أفترض أن أدنى الأنظمة الأساسية المدعومة هي Node 6 و IE11؟

تم إعدادglixlur Appveyor حاليًا لاختبار العقدة 4. هل سيجعل ذلك الأمور أكثر صعوبة؟ من الناحية المثالية ، سيكون Babel يحول مجلدًا src/ إلى مجلد (مجلدات) lib/ (و dist/ للمتصفح) للتوزيع على Node / browser. لذلك أفترض أن Babel يقوم بمعظم أعمال التحويل إلى ES5.

تم ، لكن يحتاج إلى إجراء الاختبارات. تم إهمال PhantomJS وليس لديه دعم لأي شيء بعد ES5.

تضمين التغريدة رد: PhantomJS ، يجب استبداله بشيء مثل Chromy. انظر: https://github.com/less/less.js/issues/3240

glixlur أيضًا ، هذا كرومي / كروم مقطوع الرأس متعلق بـ: https://github.com/less/less.js/issues/3262

glixlur بخصوص PhantomJS - يتم تشغيل هذه الاختبارات مقابل إصدار المستعرض المجمع ، والذي من المفترض أن تقوم بتحويله إلى ES5 ، أليس كذلك؟ لماذا لا يعمل PhantomJS مع حزمة الإخراج ES5؟

@ matthew-dean نعم ، ولكن هناك خطأ حيث يتم استخدام Symbol عند تشغيل PhantomJS بملف Babel-transpiled.

glixlur أنت بحاجة إلى babel-polyfill في الإخراج المترجم. هذا مؤشر جيد أنه لم يتم نقله بشكل صحيح بعد. راجع مشكلات مثل: https://github.com/babel/babel-preset-env/issues/203

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

يضيف @ matthew-dean babel-polyfill 87.3 كيلوبايت مصغرًا إلى ملف الإخراج. ربما لا تريد ذلك.

تضمين التغريدة
هناك أسباب أخرى لعدم رغبتك في babel-polyfill . وهي حقيقة أنه يؤثر على مساحة الاسم العالمية من خلال نشر polyfills على window وتعديل النماذج الأولية للأنواع الأصلية مثل Array .

ابحث عن حزمة babel-runtime و babel-plugin-transform-runtime الحزمة بدلاً من ذلك.

أيضًا ، يعمل فريق iirc the Babel على الحد من حزم polyfills المجمعة بمقدار transform-runtime على غرار ما يحد من تحويلات اللغة المعينة مسبقًا babel-env . لكن عملهم على ذلك لم ينته بعد وهو متاح بشكل عام. سينتهي الأمر بشيء Babel 7 ، والذي لا يزال في مرحلة تجريبية على أي حال ، لذلك ليس مفيدًا بشكل مباشر. لكن بالتأكيد مرغوب فيه للمستقبل.

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

باستخدام إعدادات Babel الصحيحة ، يجب أن يمنحك تعريفًا محددًا Symbol

سوف تفعل ذلك بالفعل.
هذه الإعدادات تصل إلى استخدام المكون الإضافي transform-runtime وقدرته على حقن الأسماء المستعارة للمكونات الإضافية الجديدة مثل Symbol ، بدلاً من الاعتماد على babel-polyfill .

هل يجب إهمال phantomjs؟

معتبرة أنها ميتة؟
ربما نعم.

glixlur انظر: https://github.com/less/less.js/issues/3240

تم التحويل ودمجها! انظر: https://github.com/less/less-meta/issues/32

Welp ، علمت هذا الأسبوع أن Class في JavaScript ليس مجرد سكر تركيبي للنماذج الأولية للوظائف ، مما تسبب في هذه المشكلة: https://github.com/less/less.js/issues/3414

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

جي ، أتساءل عما إذا كان تحويل ES6 مقابل أقل قد يتسبب في هذا النوع من المشكلات.

حسنًا: أجاب السؤال ، على ما أظن؟

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

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

مثل ، إذا قام شخص ما باختراق النماذج الأولية في مكتبتك ، فكيف تقوم بالبرمجة بشكل دفاعي لذلك ؟؟

🤷‍♂

تضمين التغريدة

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

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

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

بلى. لقد كانت خادعة

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

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

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

مثل ، إذا قام شخص ما باختراق النماذج الأولية في مكتبتك ، فكيف تقوم بالبرمجة بشكل دفاعي لذلك ؟؟

أنت لا تفعل ذلك حرفيا.

إنه مثل الأشخاص الذين يشكون من أن IL وقت التشغيل المنظم بعناية للوصول إلى الأعضاء الخاصين في C # فواصل عبر الإصدارات الثانوية. إذا كنت تتدخل في الأمور الداخلية ، فيجب أن تعرف ما الذي تشتريه. :ابتسامة:

rjgotten الحديث عن إعادة الهيكلة ...

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

كان هناك بعض النقاش حول ما إذا كانت TypeScript مقابل JS الحديثة هي الحل أم لا. لقد أدركت أن عدم وجود أنواع أو واجهات كائنات واضحة يجعل من الصعب جدًا في بعض الأحيان التفكير في قاعدة الشفرات الأقل بطريقة لا يمكن لأي قدر من التوثيق حلها أو حتى يمكن لـ JSDocs حلها.

لقد قمت بإعداد خط الأنابيب الجديد للسماح بفحص TypeScript _if_ لديك أنواع مناسبة في JSDoc ، ولكن استخدام JSDoc للكتابة أكثر وضوحًا / ضوضاء بصريًا من TypeScript ، وهناك بعض ميزات الكتابة التي لا يدعمها TS فقط عبر تعليقات JSDoc التوضيحية وحدها . لا توجد مجموعة أدوات JSDoc / ESLint يمكنها حل بعض هذه الأشياء التي يوفرها لك TS مجانًا.

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

على سبيل المثال ، هناك عدد من الميزات التي يمتلكها Less والتي تعتمد أثناء التقييم على خاصية Ruleset للعقدة paths . من هذا المُنشئ ، هل يمكن أن تخبرني ما هي خاصية paths ، وما الشكل الذي ستتخذه؟ (تلميح: لا يمكنك ذلك ، لأنه ليس موجودًا.)

في TypeScript (مع إعدادات tsconfig الشائعة) ، لن يُسمح بهذا. لن يتم تجميعها حتى. ستضطر إلى تحديد شكل paths ، وماذا سيكون بالضبط ، والذي بدوره سيعطي وثائق واضحة ومحددة (وتلميحات التعليمات البرمجية) لشخص ما يستكشف قاعدة الكود.

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

هذا فقط أنا أفكر إلى أين أذهب من هنا ، وطرق منع نقاط الألم في المستقبل.

_ ( ملحق : في حال لم يكن الأمر واضحًا ، فأنا لا أقوم 100٪ بإلحاق الضرر بالعمل التاريخي لأي شخص في قاعدة البيانات الأقل. وهناك الكثير من الأشياء التي اقترحتها ، وحصلت على دعم ، ودمجت في قاعدة الشفرة التي أنا الآن أنا مثل ، "عفوًا ، أتمنى لو لم أفعل ذلك" ، أو تمنيت لو فعلت ذلك بشكل مختلف. ولقد أضفت بالتأكيد أشياءً أدركت الآن أنها ربما أثرت سلبًا على قابلية الصيانة. لقد بذل الجميع قصارى جهدهم.) _

@ ماثيو دين
لقد قمت بإعداد خط الأنابيب الجديد للسماح بفحص TypeScript إذا كان لديك أنواع مناسبة في JSDoc ، ولكن استخدام JSDoc للكتابة هو waaaaaaaay أكثر إسهابًا / ضوضاءً بصريًا من TypeScript ، وهناك بعض ميزات الكتابة التي لا يدعمها TS عبر التعليقات التوضيحية لـ JSDoc وحدها . لا توجد مجموعة أدوات JSDoc / ESLint يمكنها حل بعض هذه الأشياء التي يوفرها لك TS مجانًا.

فعلا؛ مررت عبر المشكلة مع دعم JSDoc لكوني كذلك بالنسبة لاستدلال الكتابة بنفسي أيضًا.
لحسن الحظ ، يمكنك استخدام ملفات إقرار .d.ts بجوار ملفات المصدر .js ، دون الحاجة إلى استخدام TypeScript الكامل والمطالبة بالمترجم.

كان العمل مع ملفات التصريح أصعب كثيرًا ، ولكن الإصدارات الحديثة من مترجم TypeScript ستربط تلقائيًا ملف .d.ts جنبًا إلى جنب مع ملف .js طالما تم تسمية كلاهما نفس الشيء.

قد يكون هذا ما تبحث عنه.

rjgotten هل يمكنك شرح المزيد (أو الارتباط إذا كنت تعرف موردًا جيدًا) ، كيف يمكن أن يعمل هذا بشكل جيد مع قاعدة بيانات Less؟ كما هو الحال في ، كيف يمكنك القيام بذلك على مستوى الملف؟ هل يوجد ملف .d.ts لكل وحدة .js ؟ أو تجمعهم؟

ما هي مزايا امتلاك ملف .d.ts مقابل مجرد استخدام TypeScript في المصدر؟ لماذا تضيع الوقت في إنشاء ملفات .d.ts بدلاً من مجرد تحديد تلك الأنواع في الملفات؟

rjgotten كنت أتحدث إلى مطور Chevrotain اليوم ، وهو يقول إن ما يفعله هو التطوير في TS _BUT_ إنه يدير بالفعل ملف api.d.ts كمصدر قلق منفصل. وبهذه الطريقة ، فإن أي تغييرات في الأنواع في الملفات المصدر (مثل عقد الشجرة) لا تغير بشكل شفاف / غير مرئي واجهة برمجة التطبيقات العامة دون تغيير صريح في ملف أنواع واجهة برمجة التطبيقات.

ثم يستخدم اختبارًا مع التأكيد على تطابق الأنواع الداخلية وأنواع واجهة برمجة التطبيقات العامة -> https://github.com/SAP/chevrotain/blob/master/packages/chevrotain/test_integration/definitions/api_type_checking.ts#L1 - L2

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

بخصوص استخدام ملفات التصريح .d.ts # $ 0 $ # $ للاحتفاظ بالكتابة .js :
في الواقع كلاهما.

إذا ذهبوا جنبًا إلى جنب ، فإن أي IDE مدعوم من قبل مترجم TypeScript للاقتراحات التلقائية والفحص وما إلى ذلك سوف يلتقط الكتابة تلقائيًا. Afaik _also_ إذا تم استيراد تلك البرامج النصية ذات الكتابة جنبًا إلى جنب من node_modules ، وهو أمر جيد جدًا.

يمكنك أيضًا وضع كتابات في ملف (ملفات) واحد (مجموعة) .d.ts مثل api.d.ts ثم استخدام JSDoc لاستيراد الأنواع المعلنة بشكل صريح. دعم JSDoc في TypeScript له نكهة خاصة @typedef لذلك مع بناء جملة الاستيراد. على سبيل المثال

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

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