مهاجرت Puppeteer به TypeScript

جک فرانکلین

ما از طرفداران بزرگ TypeScript در تیم DevTools هستیم - به حدی که کدهای جدید در DevTools در حال ایجاد در آن هستند و ما در میانه یک مهاجرت بزرگ از کل پایگاه کد به بررسی نوع توسط TypeScript هستیم. می‌توانید در بحث ما در Chrome Dev Summit 2020 درباره این انتقال اطلاعات بیشتری کسب کنید. بنابراین کاملا منطقی است که به انتقال پایگاه کد Puppeteer به TypeScript نیز نگاه کنیم.

برنامه ریزی برای مهاجرت

هنگام برنامه ریزی نحوه مهاجرت، می خواستیم بتوانیم در مراحل کوچک پیشرفت کنیم . این کار سربار انتقال را پایین نگه می‌دارد—شما در هر زمانی فقط روی بخش کوچکی از کد کار می‌کنید—و همچنین ریسک را کاهش می‌دهد. اگر با یکی از مراحل مشکلی پیش آمد، می توانید به راحتی آن را برگردانید. Puppeteer کاربران زیادی دارد و انتشار خراب برای بسیاری از آنها مشکل ایجاد می کند، بنابراین بسیار مهم بود که خطر شکستن تغییرات را به حداقل برسانیم.

ما همچنین خوش شانس بودیم که Puppeteer مجموعه ای قوی از تست های واحد را در محل دارد که تمام عملکردهای آن را پوشش می دهد. این بدان معناست که می‌توانیم مطمئن باشیم که هنگام مهاجرت، کد را شکسته‌ایم، اما همچنین تغییراتی را در API خود ایجاد نمی‌کنیم. هدف از مهاجرت تکمیل آن بدون اینکه هیچ کاربر Puppeteer حتی متوجه شود که ما مهاجرت کرده‌ایم، کامل می‌شود، و آزمایش‌ها بخش مهمی از این استراتژی بودند. اگر پوشش تست خوبی نداشتیم، قبل از ادامه مهاجرت آن را اضافه می کردیم.

انجام هرگونه تغییر کد بدون آزمایش خطرناک است، اما تغییراتی که در آن شما کل فایل‌ها یا کل پایگاه کد را لمس می‌کنید بسیار خطرناک است. هنگام ایجاد تغییرات مکانیکی، به راحتی می توان یک مرحله را از دست داد، و در موارد متعدد آزمایش ها مشکلی را پیدا کردند که هم از مجری و هم بازبینی کننده عبور کرده بود.

یکی از کارهایی که ما برای آن سرمایه گذاری کردیم ، راه اندازی یکپارچه سازی مداوم (CI) ما بود. ما متوجه شدیم که اجراهای CI در برابر درخواست‌های کشش ضعیف بودند و اغلب ناموفق بودند. این به قدری اتفاق می‌افتد که ما عادت کرده‌ایم CI خود را نادیده بگیریم و به هر حال درخواست‌های کشش را با هم ادغام کنیم، با این فرض که این شکست یک مشکل یکباره در CI است تا مشکلی در Puppeteer.

پس از مدتی تعمیر و نگهداری کلی و زمان اختصاص داده شده برای رفع برخی از تکه های آزمایشی معمولی، ما آن را به وضعیت بسیار بهتری رسیدیم که به ما امکان می دهد به CI گوش دهیم و بدانیم که یک شکست نشان دهنده یک مشکل واقعی است. این کار پر زرق و برق نیست، و تماشای اجراهای بی پایان CI خسته کننده است، اما بسیار حیاتی بود که مجموعه آزمایشی ما با توجه به تعداد درخواست های کششی که مهاجرت به آن وارد می کرد، به طور قابل اعتماد اجرا شود .

یک فایل را انتخاب و فرود آورید

در این مرحله، ما مهاجرت خود را آماده کرده بودیم و یک سرور CI قوی پر از آزمایشات برای تماشای پشت ما داشتیم. به‌جای بررسی هر فایل دلخواه، ما به طور هدفمند یک فایل کوچک را برای انتقال انتخاب کردیم . این یک تمرین مفید است زیرا به شما امکان می دهد روند برنامه ریزی شده ای را که می خواهید انجام دهید تأیید کنید. اگر روی این فایل کار کند، رویکرد شما معتبر است. اگر نه، می توانید به صفحه طراحی برگردید.

علاوه بر این، فایل به فایل (و با نسخه‌های معمولی Puppeteer، بنابراین همه تغییرات در همان نسخه npm ارسال نشد) خطر را کاهش داد. ما DeviceDescriptors.js به عنوان اولین فایل انتخاب کردیم ، زیرا یکی از ساده‌ترین فایل‌ها در پایگاه کد بود. انجام این همه کار آماده سازی و ایجاد چنین تغییر کوچکی ممکن است کمی خسته کننده به نظر برسد، اما هدف این نیست که فوراً تغییرات بزرگی ایجاد کنید، بلکه باید با احتیاط و روشمند فایل به پرونده پیش بروید. زمان صرف شده برای اعتبارسنجی رویکرد قطعاً در زمان بعدی در مهاجرت زمانی که به فایل‌های پیچیده‌تر ضربه می‌زنید، در زمان صرفه‌جویی می‌کند.

الگو را ثابت کنید و تکرار کنید

خوشبختانه تغییر به DeviceDescriptors.js با موفقیت وارد پایگاه کد شد و برنامه همانطور که ما امیدوار بودیم کار کرد! در این مرحله، شما آماده هستید که به زانو در بیایید و با آن ادامه دهید، این دقیقاً همان کاری است که ما انجام دادیم . استفاده از برچسب GitHub یک روش بسیار خوب برای گروه بندی همه درخواست های کششی با هم است، و ما متوجه شدیم که برای پیگیری پیشرفت مفید است.

انتقال آن را دریافت کنید و بعداً آن را بهبود بخشید

برای هر فایل جاوا اسکریپت، فرآیند ما به این صورت بود:

  1. نام فایل را از .js به .ts تغییر دهید .
  2. کامپایلر TypeScript را اجرا کنید .
  3. هر گونه مشکل را برطرف کنید .
  4. درخواست کشش را ایجاد کنید.

بیشتر کار در این درخواست های کششی اولیه استخراج رابط های TypeScript برای ساختارهای داده موجود بود. در مورد اولین درخواست کششی که DeviceDescriptors.js منتقل کرد و قبلاً در مورد آن صحبت کردیم، کد از این زیر است:

module.exports = [
  { 
    name: 'Pixel 4',
    … // Other fields omitted to save space
  }, 
  …
]

و تبدیل شد:

interface Device {
  name: string,
  …
}

const devices: Device[] = [{name: 'Pixel 4', …}, …]

module.exports = devices;

به عنوان بخشی از این فرآیند، به این معنی بود که ما در هر خط از پایگاه کد برای بررسی مشکلات کار می کردیم. مانند هر پایگاه کدی که حدوداً چند سالی ساخته شده و در طول زمان رشد کرده است، مناطق فرصتی برای اصلاح کد و بهبود وضعیت وجود دارد. به خصوص با انتقال به TypeScript، مکان‌هایی را دیدیم که تغییر ساختار جزئی کد ما را قادر می‌سازد بیشتر به کامپایلر تکیه کنیم و ایمنی نوع بهتری داشته باشیم.

از نظر شهودی، بسیار مهم است که از ایجاد این تغییرات فوراً مقاومت کنید . هدف از مهاجرت، وارد کردن پایگاه کد به TypeScript است، و همیشه در طول یک مهاجرت بزرگ باید به خطر ایجاد شکستگی در نرم افزار و کاربران خود فکر کنید. با حداقل نگه داشتن تغییرات اولیه، این ریسک را پایین نگه داشتیم. هنگامی که فایل ادغام شد و به TypeScript منتقل شد، می‌توانیم تغییرات بعدی را برای بهبود کد برای استفاده از سیستم نوع ایجاد کنیم. اطمینان حاصل کنید که برای مهاجرت خود مرزهای سختی تعیین کرده اید و سعی کنید در آنها بمانید.

انتقال آزمایش ها برای آزمایش تعاریف نوع ما

هنگامی که کل کد منبع را به TypeScript منتقل کردیم، می‌توانیم تمرکز خود را روی تست‌های خود قرار دهیم. تست های ما پوشش بسیار خوبی داشتند، اما همه با جاوا اسکریپت نوشته شده بودند. این بدان معنی بود که یک چیزی که آنها آزمایش نکردند، تعاریف نوع ما بود. یکی از اهداف بلندمدت پروژه (که هنوز در حال کار روی آن هستیم) این است که تعاریف نوع با کیفیت بالا را با Puppeteer ارسال کنیم، اما هیچ بررسی در پایگاه کد خود درباره تعاریف نوع خود نداشتیم.

با انتقال آزمایش‌ها به TypeScript (پیروی از همان فرآیند، فایل به فایل)، مشکلاتی را در TypeScript خود پیدا کردیم که در غیر این صورت به کاربران واگذار می‌شد تا برای ما پیدا کنند. اکنون تست های ما نه تنها تمام عملکردهای ما را پوشش می دهند، بلکه به عنوان یک بررسی کیفیت TypeScript ما نیز عمل می کنند !

ما قبلاً به‌عنوان مهندسانی که روی پایگاه کد Puppeteer کار می‌کنند، از TypeScript بسیار سود برده‌ایم. همراه با محیط CI بسیار بهبود یافته ما، به ما این امکان را می دهد که هنگام کار بر روی Puppeteer بهره وری بیشتری داشته باشیم و تایپ اسکریپت باگ هایی را شناسایی کند که در غیر این صورت آن را به نسخه npm تبدیل می کرد. ما هیجان زده هستیم که تعاریف TypeScript با کیفیت بالا را ارسال کنیم تا همه توسعه دهندگانی که از Puppeteer استفاده می کنند را قادر می سازد از این کار نیز بهره مند شوند.

کانال های پیش نمایش را دانلود کنید

استفاده از Chrome Canary ، Dev یا Beta را به عنوان مرورگر توسعه پیش‌فرض خود در نظر بگیرید. این کانال‌های پیش‌نمایش به شما امکان دسترسی به جدیدترین ویژگی‌های DevTools را می‌دهند، به شما اجازه می‌دهند APIهای پلتفرم وب پیشرفته را آزمایش کنید و به شما کمک می‌کنند تا قبل از کاربران، مشکلات سایت خود را پیدا کنید!

با تیم Chrome DevTools در تماس باشید

از گزینه‌های زیر برای بحث در مورد ویژگی‌های جدید، به‌روزرسانی‌ها یا هر چیز دیگری مربوط به DevTools استفاده کنید.