Biome می‌تواند بخشی از کار lint، formatting و مرتب کردن importها را در یک ابزار انجام دهد، اما این به معنی جایگزینی خودکار ESLint و Prettier در هر پروژه نیست. معیار مهاجرت، پوشش نیاز همان پروژه است: زبان فایل‌ها، ruleهای ضروری، pluginها و قرارداد تیم. ادعای قبلی این مقاله دربارهٔ سرعت سی‌وپنج‌برابری در همهٔ شرایط حذف شده است. بدون نام پروژه، نسخهٔ ابزار، نوع کار و روش اندازه‌گیری، چنین عددی راهنمای انتخاب مناسبی نیست.
فرض کنید یک تیم فقط چند rule رایج JavaScript و تنظیم‌های سادهٔ formatter دارد. مسیر بررسی Biome برای آن تیم با پروژه‌ای که rule سفارشی برای قرارداد تجاری نوشته، متفاوت است. در پروژهٔ دوم، حذف rule بدون جایگزین ممکن است یک کنترل مهم را از فرایند مرور کد بردارد. ابزار تازه را باید در برابر فهرست نیازها بررسی کرد، نه صرفاً تعداد packageهای موجود. کمتر شدن dependency زمانی مفید است که کنترل لازم هم حفظ شود.
Formatter و Linter مسئولیت یکسان ندارند
Formatter شکل نوشتن کد را تنظیم می‌کند: فاصله‌ها، شکست خط و بعضی انتخاب‌های نگارشی. Linter الگوهایی را گزارش می‌کند که با مجموعهٔ ruleهای انتخاب‌شده ناسازگارند. تغییر ظاهر یک تابع، صحت منطق آن را ثابت نمی‌کند. اگر تابع عدد اشتباه برگرداند، خروجی خوش‌قالب همچنان اشتباه است. در معرفی ابزار کیفیت کد، این مرز باید حفظ شود تا تیم از گزارش بدون خطا، نتیجهٔ تضمین عملکرد برنامه نگیرد.
مرجع Linter در Biome ruleها و قرارداد تحلیل را توضیح می‌دهد. فعال کردن همهٔ ruleها بدون شناخت هدفشان، ممکن است گزارش‌هایی ایجاد کند که تیم مرتب نادیده می‌گیرد. بهتر است از مجموعه‌ای قابل توضیح شروع کنید و استثناها را به نیاز واقعی وصل کنید. اگر یک rule مشکل مشخصی از پروژه را می‌گیرد، دلیل نگه داشتنش روشن است. اگر فقط دربارهٔ ترجیحی سلیقه‌ای بحث ایجاد می‌کند، قرارداد تیم باید پیش از اجبار تعیین شود.
شروع کوچک در یک پوشهٔ مستقل
برای نمونهٔ آموزشی، Node.js و npm در دسترس داشته باشید و در یک پوشهٔ تازه npm init -y را اجرا کنید. سپس با npm i -D -E @biomejs/biome ابزار را نصب کنید. گزینهٔ E نسخهٔ دقیق را در package.json ثبت می‌کند. با npx biome init فایل تنظیم بسازید و همان فایل تولیدشده را نگه دارید تا Schema آن با نسخهٔ نصب‌شده هماهنگ باشد. این مراحل مطابق راهنمای رسمی شروع Biome هستند.
فایل demo.js را با محتوای زیر کنار package.json قرار دهید. این کد یک تابع مستقل برای محاسبهٔ جمع دارد و به HTML، مرورگر یا API نیاز ندارد. شکل فاصله‌گذاری عمداً فشرده نوشته شده تا نقش formatter معلوم شود. تابع سه عدد نمونه را جمع می‌کند؛ این دادهٔ آموزشی برای بررسی ظاهر کد است و نتیجهٔ یک آزمون کیفیت تجاری نیست. هیچ متغیر یا فایل معرفی‌نشده‌ای در نمونه استفاده نشده است.
function sum(values){return values.reduce((total,value)=>total+value,0)}
console.log(sum([2,4,6]));
فرمان npx biome check demo.js را در همان پوشه اجرا کنید. این مرحله گزارش می‌دهد و قرار نیست تغییر خودکار را به جای تصمیم شما انجام دهد. اگر می‌خواهید اصلاح‌های ایمن و formatting اعمال شوند، npx biome check --write demo.js را اجرا کنید و تغییر فایل را بخوانید. برای اجرای خود مثال نیز node demo.js کافی است. روش اجرا برای خواننده نوشته شده؛ این مقاله ادعای اجرای نمونه یا اندازه‌گیری سرعت در محیطی مشخص ندارد.
اصلاح خودکار را با مرور خروجی همراه کنید
یک ابزار ممکن است بعضی اصلاح‌ها را ایمن بداند و بعضی را نیازمند توجه بیشتر گزارش کند. این دسته‌بندی جای شناخت پروژه را نمی‌گیرد. هنگام مهاجرت، تغییرهای گستردهٔ خودکار را با تغییر منطق محصول مخلوط نکنید. اگر یک diff فقط formatting دارد، مرورگر کد می‌تواند آن را با هدف مشخص ببیند. اگر همان diff حذف یک شرط تجاری هم دارد، تشخیص تغییر مهم سخت‌تر می‌شود. دامنهٔ هر تغییر باید در توضیح آن معلوم باشد.
در نمونهٔ demo.js هدف فقط شکل کد و ruleهای فعال است. برای پروژهٔ واقعی، مسیر فایل‌ها، فایل‌های تولیدشده و خروجی build را مشخص کنید. formatter نباید روی فایل‌هایی کار کند که منبع اصلی‌شان در جای دیگری تولید می‌شود، مگر این رفتار عمداً در فرایند تعریف شده باشد. اصلاح مستقیم خروجی تولیدشده معمولاً در تولید بعدی از بین می‌رود. فهمیدن مرز منبع و خروجی از انتخاب ابزار هم مهم‌تر است و باید در تنظیم مشترک دیده شود.
پوشش ruleها را پیش از حذف ابزار قبلی ببینید
فهرست ruleهای ESLint را به چند گروه تقسیم کنید: خطاهای رایج زبان، قرارداد کتابخانه‌ها و ruleهای ویژهٔ پروژه. سپس برای هر نیاز بررسی کنید Biome چه پوششی دارد. شباهت نام دو rule الزاماً به معنی رفتار یکسان نیست. یک rule ممکن است مثال‌های متفاوتی را گزارش کند یا تنظیم‌های کمتری داشته باشد. جایگزین کردن باید با بررسی مواردی انجام شود که تیم واقعاً به آن‌ها متکی است؛ حذف صرفِ فایل تنظیم نشانهٔ تکمیل مهاجرت نیست.
راهنمای رسمی مهاجرت از ESLint و Prettier ابزارهای تبدیل و محدودیت‌های مرتبط را توضیح می‌دهد. خروجی تبدیل را به‌عنوان شروع مرور بگیرید. اگر موردی منتقل نشده، تعیین کنید حذف آن پذیرفته است یا کنترل دیگری باید بماند. این تصمیم را در یادداشت مهاجرت ثبت کنید. همکار بعدی نباید از نبود rule نتیجه بگیرد که تیم عمداً همان رفتار را مجاز کرده، در حالی که تبدیل فقط آن را نادیده گرفته است.
Formatting تازه ممکن است با خروجی قبلی فرق کند
هدف formatter سازگاری ظاهر کد با قرارداد خودش است و همهٔ جزئیات آن لزوماً با Prettier برابر نیستند. اگر تیم به خروجی خاصی وابسته است، چند فایل نماینده انتخاب کنید: TypeScript، JSX، JSON و زبان‌های واقعاً مصرف‌شده. فقط یک فایل سادهٔ JavaScript نمی‌تواند رفتار تمام مخزن را نمایندگی کند. اختلاف formatting را با خطای اجرای برنامه یکی ندانید، اما اثر آن بر diffها و همکاری را در تصمیم مهاجرت حساب کنید.
وقتی پروژه چند زبان دارد، پشتیبانی هرکدام را جدا بررسی کنید. وجود parser یا formatter برای یک زبان، به معنی پوشش ruleهای مشابه زبان دیگر نیست. لازم نیست برای رسیدن به شعار «یک ابزار» بخش بدون پوشش را رها کنید. ممکن است تیم در دورهٔ انتقال، ابزار دیگری را برای دامنه‌ای محدود نگه دارد. این مرز باید در فرمان‌ها و تنظیم editor روشن باشد تا دو ابزار روی یک فایل تغییرهای ناسازگار انجام ندهند.
Editor و CI باید قرارداد مشترک داشته باشند
اگر editor یک نفر هنگام ذخیره Prettier اجرا کند و CI از Biome انتظار داشته باشد، فایل مرتب میان دو شکل جابه‌جا می‌شود. انتخاب formatter پیش‌فرض و دامنهٔ فایل‌ها را همراه نصب ابزار ثبت کنید. نسخهٔ محلی نیز باید با نسخهٔ CI هماهنگ باشد. یک اختلاف کوچک نسخه ممکن است خروجی متفاوت ایجاد کند و تیم را به دنبال خطایی ببرد که از کد محصول نیست. فایل lock و تنظیم مشترک به همین دلیل بخشی از قرارداد‌اند.
برای CI، فرمان بررسی بدون نوشتن معمولاً باید نتیجهٔ ناسازگاری را گزارش دهد تا تغییر در جریان مرور انجام شود. اصلاح مخفی فایل‌ها در یک مرحلهٔ دور از دید توسعه‌دهنده، فهم علت شکست را سخت می‌کند. پیام راهنمای تیم را روشن بنویسید: کدام فرمان محلی همان بررسی را انجام می‌دهد و خروجی به چه فایل‌هایی مربوط است. برای ادامهٔ این قرارداد، راهنمای NPM Scripts به نام‌گذاری فرمان‌های مشترک کمک می‌کند.
سرعت را برای همان کار اندازه بگیرید
اجرای کامل روی مخزن، بررسی فایل‌های تغییرکرده و formatting هنگام ذخیره سه سناریوی متفاوت‌اند. اگر شکایت تیم از تأخیر editor است، عدد مربوط به مخزن بزرگ الزاماً پاسخ آن نیست. دستگاه، تعداد فایل‌ها و تنظیم ruleها را هنگام مقایسه ثابت نگه دارید. حذف ruleهای مهم برای رسیدن به عدد بهتر، مقایسهٔ برابر نمی‌سازد. نتیجهٔ اندازه‌گیری باید با همان دامنه گزارش شود و به همهٔ پروژه‌ها تعمیم داده نشود.
برای تصمیم نهایی، فهرست نیازها و اختلاف‌های پیدا‌شده را نگه دارید. اگر پوشش کافی است و قرارداد editor و CI روشن شده، مهاجرت می‌تواند دلیل عملی داشته باشد. اگر rule یا زبان ضروری بدون پوشش مانده، ابتدا مسیر آن را حل کنید. Biome گزینه‌ای قابل بررسی برای کیفیت کد است؛ آیندهٔ قطعی همهٔ ابزارها یا بهترین انتخاب هر تیم نیست. ارزش آن را رفتار واقعی در پروژهٔ خودتان مشخص می‌کند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!