Typescript: إضافة خيار moduleResolution جديد: `yarn-pnp`

أعتقد أننا نفضل أن يتم تسوية yarn و npm على تنسيق مشترك - نظرًا لأن npm يعمل على tink الذي يفعل نفس الشيء مع .package-map.json . بغض النظر ، لدينا موقف تقليدي في الوقت الحالي بعدم تنفيذ JS الخارجية كجزء من بناء (ربما سيتغير ذلك في المستقبل ، لكن هذه فلسفتنا الدائمة حاليًا) ، لذلك شيء من هذا القبيل ، على الأقل ، سيتم حظره على https : //github.com/yarnpkg/yarn/issues/6388 بالنسبة لنا.

دانيال لديه تعليق أكثر تفصيلاً على pnp rfc هنا

هذا يبدو معقولًا تمامًا ، شكرًا weswigham

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

الطريقة الأكثر عمومية للقيام بذلك هي ببساطة كشف resolveModuleName ضمن ملفات tsconfig (https://github.com/Microsoft/TypeScript/issues/18896) ، تمامًا كما فعلنا مقابل ts-loader (https://github.com/TypeStrong/ts-loader/pull/862). ستكون ميزة مفيدة لن تفتح فقط PnP لمستخدمي tsc ، ولكن أيضًا حالات استخدام أخرى لمؤلفي الأدوات الآخرين. أعتقد أيضًا أنه لن يتعارض مع سياستك الافتراضية لعدم تنفيذ التعليمات البرمجية الخارجية ، حيث سيتطلب إقرارًا صريحًا من المستخدم.

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

كي لا نقول إننا لن نعيد النظر فيه في وقت ما ، ولكن بالتأكيد تم رفض اقتراحات مماثلة مرارًا وتكرارًا في الماضي. التنسيق الثابت أسهل بكثير في التعامل معه.

أفهم ، لقد أبلغتك ببساطة أن الانتظار https://github.com/yarnpkg/yarn/issues/6388 لن يكون خيارًا على الأرجح 🙂

شيء آخر نسيت أن أذكره - في عالم يكون فيه tsc يحتوي على دعم مدمج ، يجب أن يكون اسم الحل هو pnp ، وليس yarn-pnp . Plug'n'Play هي مواصفات عامة مصممة بطريقة يمكن من خلالها تنفيذها بواسطة بائعين مختلفين ، وليس فقط بواسطة Yarn.

سأحب فقط إذا كان من السهل تجاوز حل اسم الوحدة النمطية في أدوات مثل tsc أو VS Code ، نظرًا لأن الغزل pnp ليس حالة الاستخدام الوحيدة لذلك ، وحزم الوحدات النمطية قابلة للتخصيص بشكل لا نهائي يعني أن الشيء الوحيد الذي يعيق الاستخدام هو حقًا المحرر الدعم (وإذا كنت تريد التوافق مع مترجم CLI). الميزة موجودة بشكل أساسي "هناك" ولكن يصعب استخدامها بدون تفرع مستقيم.

سيكون هناك دائمًا طلب على طرق مخصصة لحل الوحدات. يعتبر نظام العقدة البيئي شخصًا جامدًا في هذا الصدد (نظرًا لأن اتفاقية node_modules "لا يمكن المساس بها") ، لكن المجتمع قام بعمل حوله (على سبيل المثال: حلول Webpack المخصصة والأسماء المستعارة). الآن هناك أيضًا pnp و tink. في HubSpot لدينا نبضة في الدقيقة خاصة بنا. تجعل جميع الأدوات تقريبًا من السهل التعامل معها (Jest و Webpack وأشياء مثل eslint-plugin-import وما إلى ذلك. أعتقد أن Flow لديه هذه الميزة الآن أيضًا؟). تحتوي خدمة اللغة TS على حل اسم الوحدة ، كما هو مذكور أعلاه. إذا فهمت جيدًا ، فهناك خطاف دقة مخصص لوحدات ES6 في العقدة الآن؟

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

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

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

أنا أفهم ما تقوله ولكن سيكون من الجيد أن يتراجع فريق TypeScript خطوة إلى الوراء وينظر إلى الصورة الأكبر هنا. من المنطقي أنك تهتم أكثر بأداء TypeScript ، لكن العديد من المستخدمين لديك يختبرون تطبيقاتهم باستخدام أنظمة CI ، ومن المهم بالنسبة لهم مدى بطء تثبيت تطبيقاتهم بقدر سرعة فحص النوع / التحويل البرمجي معالجة.

على سبيل المثال ، يستغرق تثبيت التطبيق الذي أستشيره حاليًا حوالي دقيقتين على CI. أود أن أنزل هذا الرقم.

هل هناك على أي حال يمكن أن يدعم TypeScript pnp بدون دعمك للمحللات المخصصة؟ إذا كانت ، كما تقول arcanis ، "مواصفات عامة" ، فلا أرى سببًا لعدم دعمها خارج الصندوق.

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

لا يمكننا دعمه بشكل مباشر كما هو ، ولكن كما يشير arcanis في مكان آخر ، يمكنك على الأرجح كتابة نص برمجي قصير لما بعد التثبيت يحول ملف .pnp.js الديناميكي إلى paths tsconfig ، على سبيل المثال خيار

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

هناك بعض القيود المحرجة هناك ، مثل التبعيات المتداخلة عندما يكون لديك إصدار متعدد من نفس الحزمة. (على سبيل المثال: تعتمد حزمة Foo على Bar @ 1 وتعتمد Baz على Bar @ 2 ، ويعتمد تطبيقك على Foo و Baz ، فأنت محظوظ بقدر ما أعرف. لا أعتقد أن الأسماء المستعارة لـ tsconfig يمكنها التعبير عن هذا).

weswigham أتساءل شيئًا ما - قد تكون على دراية بأن مشروع Node يعمل على توحيد اللوادر. ألا يجعل منهجك غير عملي على المدى المتوسط ​​والطويل؟

شيء يجب ذكره فيما يتعلق بالأداء - لقد لاحظنا بالفعل أداء أفضل قليلاً في Flow عندما يستخدم PnP ، وهو أمر منطقي نظرًا لأن دقة PnP تزيل الكثير من مكالمات stat .

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

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

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

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

3. يجب دمج @ أنواع / حزم في tsconfig / المسارات لنظرائهم من الحزم "الحقيقية".
   لا أعرف ما هي آثار ذلك على عملية التجميع ، لكنها بالتأكيد تبدو وكأنها شيء يمكن أن يسبب مشاكل.

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

weswigham هل ستكون منفتحًا على حل وسط؟

أريد الاحتفاظ بالملف .pnp.js مكتملًا ، لأنه يوفر الكثير من الوحدات النمطية التي أظن أننا سنحتاجها. في الوقت نفسه ، أتفهم بعض المخاوف التي لديك ، لذا دعني ألخصها للتأكد من أنني استوعبت جوهر المشكلة بشكل صحيح:

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

• في نفس الوقت ، لا ترغب في توفير روابط التعليمات البرمجية في المترجم tsc لأنه ، نظرًا لاستخدامه بواسطة vscode ، فقد يؤدي إلى نوع من تنفيذ التعليمات البرمجية بمجرد فتح ملف TS في vscode.

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

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

في الأساس ، شيء من هذا القبيل:

.pnp.js

const staticTable = /*table-start*/{
  "lodash": "./cache/lodash-1.0.0",
}/*table-end*/;

exports.resolveName = name => staticTable[name];

tsc-pnp

const pnpJs = readFileSync(pnpJsPath, `utf8`);
const [,table] = pnpJs.match(/\/\*table-start\*\/(.*)\/\*table-end\*\//);
const staticTable = JSON.parse(table);

exports.resolveName = name => staticTable[name];

هذا من شأنه أن يحل المشاكل المذكورة أعلاه:

• ستظل متحكمًا في أداء الدقة ، وستكون قادرًا على التأكد من أننا لا نضع while(true) ضخمًا

• لن يقوم VSCode بتنفيذ تعليمات برمجية غير موثوق بها افتراضيًا - سيكون لديك التحكم في متى ولماذا تريد ترقية حزمة tsc-pnp إلى إصدارات جديدة ، وسوف تمر عبر عمليات العلاقات العامة الكلاسيكية ، مما يجعلها قابلة للتتبع.

الآن ، قد تتساءل "ما الفرق بين مجرد استخدام ملف json؟" - الفرق هو أنه في هذه الحالة ، يحتفظ Yarn بالتحكم في تخطيط ملف .pnp.js ، ويعامله قليلاً كمورد معتم. هذا من شأنه أن يمنحنا مجال العرض الذي نريده / نحتاجه لإجراء التغييرات. أعترف حتى أنني أجد الموقف مؤسفًا بعض الشيء (لن يعمل مع تطبيقات PnP المختلفة) ، ولكن يبدو أنها أفضل طريقة للمضي قدمًا في هذا الأمر.

هل سيكون فريقك منفتحًا للنقاش حول مثل هذا الحل؟ أتوقع أن تكون هناك حاجة إلى بعض التنقيح بالطبع 🙂

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

لذلك سيكون الحل ، إذا كنت لا تثق في ملف .pnp.js في المستودع ، ببساطة لإعادة تكوينه من داخل VSCode (في هذه الحالة ، سيتم شحنه مع "نواة صغيرة من الغزل"). سيكون هذا سريعًا (شبكة صفرية لأنها ستستهلك فقط بيانات ملف القفل الحالية ، صفر I / O ، لأنه مع نموذج v2 الخاص بنا ، ندعو إلى تخزين أرشيفات الحزمة في المستودع) ، وآمنة (لن يتم تشغيل أي رمز غير موثوق به عند فتح ملف).

ماذا تعتقد؟ بدأ Yarn في الانتقال إلى TS ، لكننا نرغب حقًا في الحصول على دعم TS لـ PnP لأنه يجعل الأشياء محرجة قليلاً بخلاف ذلك. حظي Flow بدعم PnP حتى قبل الإصدار 🙂

اعتقدت أن PnP بدا ممتعًا للغاية ، وأردت تجربته قبل أن أدرك أن VSCode و Typescript لن يكونا قادرين على العثور على ملفات d.ts بشكل صحيح. تعد الكتابة النصية أداة مهمة ، وأعتقد أن تجربة PnP سيتم حظرها حتى يتم دعمها بطريقة معقولة بواسطة TS. 😅

لا يقتصر الأمر على حظر yarn-pnp فحسب ، ولكن مع التقاط TypeScript للكثير من القوة ، فإنه يحظر أي نوع من الابتكار في النظام البيئي بأكمله ما لم توافق عليه Microsoft ، وهو أمر غير رائع حقًا.

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

عذرًا إذا كان هذا نوعًا من التعليق "+1" ، ولكن يبدو أن هناك حلولًا مقترحة بالفعل وهذا في حالة حيث كل ما هو مطلوب هو التزام من فريق TypeScript.
لقد حاولنا استخدام Yarn PnP في Jest repo قبل وبعد الترحيل من Flow إلى TypeScript ، وهذا هو حاليًا أكبر مانع ، والآخر الكبير إلى حد ما هو قواعد استيراد ESLint.
أعتقد أن هذا ضروري حقًا لمساعدة PnP على اكتساب قوة الدفع ، لأنه يمكّن المشاريع الكبيرة الأخرى التي تعتمد على TypeScript في عملية التحقق / الإنشاء من استخدام PnP ، مما يساعدها على النضج وتصبح أكثر وضوحًا كبديل عملي لـ node_modules 🚀

لقد ركضت للتو إلى هذا. أنا لا أحاول حتى pnp - كنت بحاجة إليه بسبب التبعيات المكررة في الدلائل المتداخلة للوحدات في monorepo ....

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

لقد قمت بإنشاء tsc-pnp - وهو بديل مؤقت لـ tsc وامتداد VSCode الذي يضيف دعم PnP إلى خدمة لغة TypeScript. احب ان اسمع ردود الفعل!

آه لطيف! تعمل Fwiwvlasenko على أداة مشابهة تسمى pnpify سنقوم tsc ، VSCode ، وأدوات أخرى مماثلة تفتقر إلى الدعم المدمج (نحن نحاكي a الدليل الظاهري node_modules ، والذي غالبًا ما يكون جيدًا بما يكفي لخداع مثل هذه الأدوات).

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

أنا أؤمن بشدة بمبادئ Typescript لعدم فتح واجهة برمجة التطبيقات لدمج المكونات الإضافية وهذا ما يجعل طريقة أدوات Typescript أكثر موثوقية من العديد من أدوات البناء الأخرى.

كما قال weswigham ، يجب أن يستقر مديرو العقدة

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

weswigham ، قد لا تنوي

على سبيل المثال ، يمكن أن ينتج مشروع PnP ملف Node.js قابل للتنفيذ يدعم PnP محليًا عن طريق القيام بشيء مثل تقليص الوحدة النمطية fs بالكامل.

هذا في الواقع هو بالضبط كيف يعمل tink exec . هل هذا التلاعب العميق (والعشوائي) هو الأفضل؟ أعتقد أن الجواب "لا".

(خاصة عندما تكون في محرر)

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

شخصياً ، كنت أنظر إلى PnP على هذا النحو: يشبه نظام الملفات ؛ مصدر قلق يختاره المستخدم ومنخفض المستوى وشامل قد يؤثر على الأداء. (لكن PnP ليس استدعاءات نظام الملفات حرفياً لأن هذه طريقة سيئة لتجريد / تنفيذ دقة الوحدة. RIP tink.)

يجب أن يستقر مديرو العقدة والحزم على معيار واحد.

متفق. Hot take: الابتكار الوحيد (الجيد) في مساحة إدارة حزمة Node.js يأتي من الغزل.

بغض النظر عن سؤال السياسة ، arcanis أعتقد أن هناك شيئًا واحدًا يفتقر إليه PnP API لـ TypeScript: الواردات المستنبطة.

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

ثم توصل TypeScript إلى خوارزمية لمحاولة إنتاج استيراد لها تلقائيًا. (الإصدار المختصر: 1. جرب node_modules 2. جرب النسبي 3. فشل إذا كان المسار النسبي يحتوي على "node_modules" فيه.)

import { a } from 'a';
export const b = a;

import { a } from 'a';
declare export const b: import('some/module').SomeType;

إما أن يعود السلوك إلى ما كان عليه من قبل (انحدار ، ولكن ليس بالضرورة كسر صفقة) ، أو يحتاج PnP API إلى reverseResolve يحسب الاستيراد من ملف إلى آخر (إن وجد).

أنا واثق من أن tink يمكن اعتباره قديمًا في هذه المرحلة ؛ غادر المشرف كات مارشان الشركة وكان آخر نشاط ملحوظ في شهر مارس.

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

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

أنا واثق من أنه يمكن اعتبار tink عفا عليه الزمن في هذه المرحلة

مجرد ملاحظة توضيحية: وفقًا لخارطة طريق npm ، لم يعد نهج tink ميتًا ومن المقرر أن يهبط في npm CLI في مرحلة ما.

لكن بالطبع أوافق على أن tink / pnpify هما حلان جيدان فقط لفترة انتقالية.

من المتوقع أن يكون

وفقًا لخارطة طريق npm ، فإن نهج tink لم يمت

ربما ، ولكن لا يزال الريبو لم يتم التطرق إليه منذ مارس و AFAIK لا يحدث أي تطور غير طبيعي بحلول npm. في حين أن آخر سيد PNP يلتزم على https://github.com/yarnpkg/berry كان يوم السبت.

يجب أن يستقر مديرو العقدة والحزم على معيار واحد. نعم ، الابتكار رائع ، لكن وتيرة التبني لا يمكن أن تكون هي نفسها وتجعل النظام البيئي بأكمله في حالة من الفوضى

تعمل الميزات الجديدة في إدارة حزم Node.js على النحو التالي:

1. غزل RFC
2. تطوير الغزل
3. تطوير npm في نهاية المطاف

لست على علم بأي عملية أخرى.

على سبيل المثال ، مع npm v7 ، فإن الميزات التي تنتقل إلى الخطوة 3 هي مساحات العمل وتجاوزات الدقة و yarn.lock.

أكمل PNP الخطوة 2. بعد عامين من الآن ، من المحتمل أن يكمل الخطوة 3.

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

Nit: هو برنامج compiler ، وليس أداة بناء مثل Make أو Ant أو Webpack.

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

أي حركة على هذا؟

ما الذي يمنع هذا الآن؟

1. آخر تحديث من فريق TS حول هذه المسألة هو نوفمبر 2018 بواسطة weswigham مشددًا على الرغبة في عدم تشغيل الخطافات الخارجية ، من أجل الاستقرار والأداء.

2. يمكن لـ PnP تحسين الأداء بسبب انخفاض عدد مكالمات الإحصائيات.

3. قدم PnP تنسيق ملف ثابت (على الرغم من أن الواجهة الأساسية هي JS).

4. لقد ماتت تقنية npm المماثلة منذ أكثر من عام.

5. pnpify tsc ، عن طريق ربط وحدة fs.

6. تم تقديم PR # 35206 في نوفمبر 2019 للحصول على الدعم المحلي (مفتوح حاليًا).

7. @ yarnpkg / plugin-Compatible يطبق هذا التصحيح تلقائيًا.