لماذا يكون TypeScript في قلب كل تطبيق ويب PayPal جديد؟

نشرنا مؤخرًا مواد انتقد فيها إريك إليوت برنامج TypeScript. نلفت انتباهكم اليوم إلى ترجمة مقالة كنت دودز. يتحدث هنا عن سبب تحول PayPal من Flow إلى TypeScript.

الخلفية

أنا أعمل في PayPal وأشارك في مكتبة paypal-scripts ، وهو صندوق أدوات يذكّر react-scripts create-react-app أو angular-cli أو ember-cli . لقد كتبت بالفعل عن هذا. أساس هذه المكتبة هو فكرة الجمع بين جميع الأدوات المستخدمة في تطبيقات PayPal وفي الوحدات النمطية المنشورة. الهدف من إنشاء paypal-scripts هو أخذ جميع تبعيات التطوير ، و devDependencies ، من package.json ، وجميع ملفات التكوين ، وتقليل كل هذا إلى إدخال واحد في قسم devDependencies . ونظرًا لأن جميع التكوينات موجودة في حزمة واحدة ، يتم خلالها التمسك بوجهة نظر محددة للغاية حول ما هو جيد ، من أجل الحفاظ على تحديث الأدوات ، يكفي تحديث تبعية واحدة فقط (في الواقع - paypal-scripts ) ، عادةً لا تحتوي التحديثات في حد ذاتها على شيء يمكن أن يعطل تشغيل التعليمات البرمجية التي تعتمد عليها. نتيجة لذلك ، يكفي الحفاظ على تبعية واحدة والمشاركة بهدوء في تطوير التطبيق.

على مدار العام الماضي ، اعتاد مبرمجو PayPal العمل مع paypal-scripts . هنا ، لإنشاء تطبيق جديد ، ما عليك سوى النقر على بضعة أزرار في واجهة الويب ، ونتيجة لذلك سيتم إنشاء مستودع GitHub للشركة ، وسيتم تكوين أدوات نشر المشروع ونظام تكامل مستمر ، وما إلى ذلك. يستند المستودع الذي تم إنشاؤه تلقائيًا إلى مستودع sample-app .

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

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

لذلك ، عرّفتك على مسار الأمور ، والآن دعنا نتحدث عن TypeScript.

في منتصف ديسمبر ، عملت على دمج paypal-scripts في sample-app . لقد عملت أيضًا (وأواصل العمل) في مشروع pp-react ، وهو عبارة عن مكتبة مكونة من مكونات (أزرار ، نوافذ ، أنماط) مناسبة لإعادة الاستخدام. بما أن paypal-scripts تدعم الوحدات النمطية التي يمكن نشرها ، فقد استخدمت react-scripts لإنشاء pp-react . وقبل شهر ، شملت مكتبة paypal-scripts دعمًا لـ Flow . كان هذا الدعم سهلاً للغاية للإضافة إلى هذه المكتبة بفضل Babel.

في الثاني عشر من كانون الأول (ديسمبر) ، عندما كنت أعمل على تطبيق pp-react والإصدار الجديد من sample-app فيما يتعلق بدعم Flow ، شعرت أنني تعبت بالفعل من Flow (سأناقش هذا بمزيد من التفاصيل أدناه) واتخذت قرارًا غير متوقع. كتبت خطابًا إلى أحد الزملاء يسأله كيف ينظر إلى ما سأحاول جعله يستخدم برنامج TypeScript في sample-app . أجاب: "نعم ، افعلها". ثم أجريت استطلاعًا حول قناة #paypal-scripts Slack ، والتي تبين أن جميع المشاركين فيها يدعمون فكرتي. بالنسبة لي ، كل هذا كان كافيا للوصول إلى العمل. بعد حوالي أسبوع ، قمت بالتبديل بالكامل للبرامج paypal-scripts من دعم Flow إلى دعم TypeScript. قضى معظم هذا الوقت في تدريس جميع الأدوات اللازمة للتعرف على .tsx .ts و .tsx ، وعلى السماح لحزمة paypal-scripts باختبار نفسها ، والتي تبين أنها مهمة صعبة للغاية. ثم أمضيت عدة أيام في العمل في قسم العلاقات العامة في مستودع sample-app ، والذي كان يهدف إلى استخدام مكتبة paypal-scripts المحسّنة الجديدة ، والتحول من ملفات .js إلى .ts و. ملفات tsx . ثم كانت هناك عطلات ، ثم تمت الموافقة على العلاقات العامة الخاصة بي. نتيجة لذلك ، الآن في كل مشروع جديد ، يستخدم PayPal كتابة TypeScript ثابتة.

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

لماذا ذهبت إلى TypeScript لفترة طويلة؟

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

لهذا السبب بقيت بعيدًا عن TypeScript طوال هذا الوقت.

number السبب رقم 1. الخوف من تدمير بيئات العمل بابل و ESLint

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

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

1. من الضروري توصيل إعداد مسبق مع دعم بناء الجملة المقابل لبابل.
2. تحتاج إلى إضافة بناء // @flow إلى بداية كل ملف ، ونوع التدقيق الذي تريد تنظيمه (هناك مكون إضافي لـ ESLint يسمح لك بالتحقق من ذلك).
3. أضف برنامجًا نصيًا إلى المشروع يسمح لك بتشغيل Flow للتحقق من الأنواع الموجودة في قاعدة الشفرة.

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

الآن كل شيء يواصل العمل كالمعتاد. بفضل Babel 7 (على وجه الخصوص ، نتحدث عن @ babel / preset-typescript ) ، يمكنك حفظ الأدوات المألوفة ، بالإضافة إلى الحصول على معظم ميزات TypeScript تحت تصرفك. المشكلة الرئيسية هي جعل الأدوات تقبل الملفات ذات الامتدادات. ts و. .tsx ، ولكن ، لحسن الحظ ، يتم حل هذه المشكلة.

number السبب رقم 2. سيتعين على المساهمين تعلم TypeScript من أجل المساهمة في المشروع.

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

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

number السبب رقم 3. نظام الاستدلال النوعي القوي

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

هكذا هو. في هذه الأيام ، يحتوي Flow على نظام استدلال نوع أقوى من TypeScript ، وقد شجعني ذلك.

number السبب رقم 4. التدفق ، مثل React ، أصلاً من Facebook

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

number السبب رقم 5. المتعصبين TypeScript

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

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

لا يزال لدي بعض المخاوف بشأن هذا. ولكني آمل أن نجعل مجتمع TypeScript أكثر إيجابية معًا.

الآن بعد أن تحدثت عن الأسباب التي تجعلني غير مستعجلة للتبديل إلى TypeScript ، سأتحدث عما لا يناسبني في Flow.

قضايا التدفق

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

تم أخيرًا دفعي بعيدًا عن Flow عن طريق المشكلات الناشئة بانتظام مع موثوقيتها. عملت الإضافات للمحررين ، إذا جاز التعبير ، بدرجات متفاوتة من النجاح (يجب أن أعترف أنني لم أعمل مع Nuclide ، وربما ، لو جربت ذلك ، كانت حياتي قد تغيرت بشكل مختلف ، لكنني حاولت العمل مع Flow in Atom وفي VSCode) ، كنت دائمًا تواجه بعض الشذوذ. كان هذا مزعجًا جدًا لأنه قوض إيماني بنظام التحكم في النوع الذي استخدمته.

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

سؤال وجواب

▍ لماذا لا تستخدم TSLint؟

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

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

وبالمناسبة ، لدي شعور بأن فريق TypeScript يميل نحو ESLint ، لذلك أعتقد أنني قمت بالاختيار الصحيح.

▍ لماذا لم تختار السبب؟

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

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

ملخص

الآن ، أود أن أشكر جميع مستخدمي Twitter الذين أثروا في رؤيتي لـ TypeScript. كما قلت ، فإن حقيقة أن مكتبة paypal-scripts دخلت في مستودع sample-app في PayPal ربما كان الإنجاز الرئيسي في حياتي المهنية. وأعتقد أن حقيقة أن القوالب الآن لجميع التطبيقات الجديدة في الشركة مجهزة بدعم TypeScript بشكل افتراضي تعد إضافة كبيرة لجميع موظفي PayPal. أنا سعيد للغاية لأنني اخترت TypeScript.

أعزائي القراء! هل تعتقد أن أولئك الذين يستخدمون Flow يجب أن ينظروا في اتجاه TypeScript؟