اختلاف درباره فاصله، کوتیشن و محل شکستن خط نباید بخش بزرگی از بازبینی کد را بگیرد. در عین حال، یک Formatter نمی‌تواند نام متغیر تعریف‌نشده یا منطق اشتباه دامنه را کامل تشخیص دهد. ESLint و Prettier مسئولیت‌های متفاوتی دارند: یکی قواعد تحلیل کد را اعمال می‌کند و دیگری قالب را یکدست می‌کند. استفاده هماهنگ آن‌ها می‌تواند بحث‌های تکراری را کم کند، به شرطی که دامنه و تنظیمات روشن باشند.
شروع مناسب یک مجموعه کوچک و قابل توضیح است. فعال‌کردن همه قواعد و افزونه‌ها ممکن است پروژه را با هزاران پیام غیرقابل رسیدگی روبه‌رو کند. ابتدا نوع فایل، محیط اجرا و قرارداد تیم را مشخص کنید. یک پروژه JavaScript ساده با React، TypeScript یا کد Node یک نیاز ندارد. آموزش قدیمی نیز ممکن است فایل تنظیم متفاوتی نشان دهد؛ نسخه ابزار و قرارداد جاری را از منبع رسمی بخوانید.
Lint و Format دو کار متفاوت‌اند
ESLint می‌تواند خطاهای محتمل و الگوهای انتخاب‌شده تیم را گزارش کند. مقدار بدون استفاده، نام ناشناخته و بعضی الگوهای مسئله‌دار نمونه‌اند. همه پیام‌ها باگ قطعی نیستند و همه باگ‌ها هم با Lint پیدا نمی‌شوند. Prettier ساختار نحوی را می‌خواند و شکل متن را طبق قواعد خود بازنویسی می‌کند. هدفش قضاوت درباره معماری یا درستی نتیجه تجاری تابع نیست. مرز این دو را در گفت‌وگوی تیم حفظ کنید.
اگر هر دو ابزار برای قالب با قواعد ناسازگار تصمیم بگیرند، ممکن است فایل مدام تغییر کند. راهنمای رسمی ادغام Prettier و Linter توصیه می‌کند مسئولیت قالب را روشن نگه دارید و قواعد متعارض را خاموش کنید. اجرای جداگانه Format و Lint نیز می‌تواند ساده و قابل فهم باشد. لازم نیست صرفاً برای داشتن یک فرمان، همه قابلیت‌ها را پشت زنجیره پیچیده پنهان کنید.
Flat Config در ESLint جاری
مستندات جاری ESLint از Flat Config با فایل‌هایی مانند eslint.config.js توضیح می‌دهد. نمونه‌های قدیمی eslintrc را بدون توجه به نسخه کپی نکنید. در تنظیم جدید، الگوهای فایل، Ignore، زبان و قواعد در ساختار مشخص تعریف می‌شوند. راهنمای رسمی Configuration Files مرجع این قرارداد است. نوع Module فایل تنظیم نیز باید با package.json و پسوند فایل هماهنگ باشد.
محیط Node و مرورگر Globalهای متفاوت دارند. افزودن همه Globalها برای ساکت‌شدن پیام‌ها می‌تواند اشتباه را پنهان کند. فایل مرورگر را با محیط خودش و فایل سرور را با محیط مناسب بررسی کنید. در نمونه پایین فقط یک Module ساده داریم که به Console، DOM یا Node API وابسته نیست؛ بنابراین نیاز به بسته Globalها نداریم. این مرز عمدی است و نباید نمونه را پیکربندی کامل React معرفی کرد.
نمونه کامل و کوچک
پوشه‌ای تازه بسازید و پنج فایل زیر را در ریشه آن قرار دهید: package.json، eslint.config.js، .prettierrc.json، .prettierignore و total.js. برای نسخه‌های انتخاب‌شده از Node ۲۲.۱۳ به بالا استفاده کنید و سازگاری نسخه دقیق نصب‌شده را بخوانید. npm install وابستگی‌ها را نصب می‌کند. سپس npm run lint کد هدف را بررسی و npm run format:check قالب فایل‌ها را بررسی می‌کند. این‌ها دستورهای خواننده‌اند و اجرای موفق آن‌ها در این مقاله ادعا نمی‌شود.
فایل package.json
{"type":"module","scripts":{"lint":"eslint total.js --max-warnings 0","format":"prettier . --write","format:check":"prettier . --check"},"devDependencies":{"eslint":"^10.0.0","@eslint/js":"^10.0.0","eslint-config-prettier":"^10.0.0","prettier":"^3.0.0"}}
فایل eslint.config.js
import js from '@eslint/js';
import prettier from 'eslint-config-prettier';
export default [
{ ignores: ['dist/**', 'node_modules/**'] },
{ files: ['**/*.js'], ...js.configs.recommended },
prettier,
];
فایل .prettierrc.json
{"singleQuote":true,"semi":true,"trailingComma":"all"}
فایل .prettierignore
node_modules
dist
package-lock.json
فایل total.js
export function sumPrices(prices) {
return prices.reduce((total, price) => total + price, 0);
}
پیکربندی از قواعد recommended بسته @eslint/js استفاده می‌کند و eslint-config-prettier در انتها قواعد قالب متعارض شناخته‌شده را خاموش می‌کند. فایل total.js یک تابع Exportشده دارد و متغیر بدون استفاده ایجاد نمی‌کند. برای بازنویسی قالب، npm run format را اجرا کنید و تغییر فایل‌ها را پیش از ثبت بخوانید. نمونه هیچ HTML یا رابطی ندارد؛ Module JavaScript مستقل است و ورودی مرورگر پنهان ندارد.
خطا را از Warning جدا کنید
قاعده می‌تواند خاموش، هشدار یا خطا باشد. تیم باید بداند کدام پیام مانع پذیرش تغییر است و چرا. در نمونه، max-warnings صفر باعث می‌شود هشدار نیز خروج ناموفق ایجاد کند؛ این یک قرارداد روشن نمونه است، نه الزام همه پروژه‌ها. اگر Warningهای قدیمی فراوان دارید، پذیرش چنین قاعده‌ای بدون برنامه رسیدگی ممکن است جریان کار را متوقف کند. ابتدا وضع موجود را بشناسید.
پیام‌ها را بی‌دلیل خاموش نکنید. اگر استثنا لازم است، محدوده و دلیل کوتاه بنویسید تا بعداً قابل بازبینی باشد. Disable کلی یک فایل برای حل یک پیام کوچک هزینه دارد. در مقابل، قاعده نامتناسب را هم فقط برای حفظ ظاهر سخت‌گیرانه نگه ندارید. مجموعه قواعد باید با نیاز تیم و نوع کد سازگار باشد. کیفیت از تعداد Warningها به تنهایی قابل اندازه‌گیری نیست.
نسخه محلی و Lockfile
ابزار را در وابستگی توسعه پروژه نگه دارید تا تیم از نسخه مرتبط استفاده کند. نصب Global متفاوت ممکن است نتیجه دیگری بدهد. Lockfile و روش نصب تکرارپذیر در تیم اهمیت دارند؛ برای تغییر واقعی باید طبق قرارداد مخزن نگهداری شوند. نسخه‌های major می‌توانند تنظیم یا رفتار را عوض کنند. راهنمای شروع ESLint و راهنمای نصب Prettier اطلاعات جاری را ارائه می‌کنند.
در نمونه، محدوده major انتخاب شده است و نصب دقیق ممکن است با گذشت زمان تغییر کند. برای محصول واقعی نسخه حل‌شده را با Lockfile ثبت کنید. تغییر ابزار و Format گسترده را از تغییر منطق جدا نگه دارید تا بازبینی روشن باشد. فایل‌هایی که فقط فاصله آن‌ها تغییر کرده نباید تغییر رفتاری مهم را پنهان کنند. انتخاب نسخه باید با محیط CI و ویرایشگر نیز هماهنگ باشد.
ویرایشگر کمک می‌کند، مرجع نهایی نیست
Format on Save می‌تواند کار روزانه را ساده کند، اما افزونه ویرایشگر ممکن است از تنظیم Global یا Formatter دیگری استفاده کند. فرمت‌کننده پیش‌فرض و تنظیم پروژه را روشن کنید. اگر فقط یک نفر فایل را متفاوت می‌بیند، ابتدا مسیر تنظیم را بررسی کنید. نتیجه فرمان محلی پروژه باید قابل توضیح باشد. اسم افزونه مشابه به معنی رفتار یکسان با نسخه نصب‌شده در پروژه نیست.
Autofix همه خطاها را حل نمی‌کند و تغییر خودکار نیز نیاز به خواندن دارد. بعضی اصلاح‌ها انتخاب معنایی می‌خواهند. اگر متغیری استفاده نمی‌شود، حذف آن شاید درست باشد یا شاید نشانه مرحله فراموش‌شده باشد. ابزار نمی‌تواند همیشه نیت را تشخیص دهد. راهنمای Clean Code به قرارداد و نام و اثر بیرونی می‌پردازد؛ این تصمیم‌ها فراتر از فاصله و علامت‌اند.
مسیر تیمی و CI
در CI می‌توان فرمان‌های بررسی را اجرا کرد تا نتیجه فقط به دستگاه یک فرد وابسته نباشد. فرمانی که فایل‌ها را بازنویسی می‌کند با فرمان بررسی بدون تغییر فرق دارد. برای پذیرش تغییر معمولاً باید معلوم باشد چه چیزی گزارش و چه چیزی اصلاح می‌شود. راهنمای CI/CD برای اتصال بررسی‌ها به تحویل مفید است. Hook محلی می‌تواند کمک کند، ولی جای مرجع مشترک تیم را نمی‌گیرد.
پوشه خروجی، فایل تولیدشده و وابستگی‌ها را مطابق نیاز Ignore کنید. حذف گسترده فایل‌های منبع از بررسی برای سبزشدن CI، کیفیت ایجاد نمی‌کند. در Monorepo، دامنه هر Package و تنظیم مشترک باید روشن باشد. اگر چند نسخه ابزار فعال‌اند، نتیجه را مستند کنید. آغاز با یک مسیر کوچک و گسترش آگاهانه معمولاً قابل فهم‌تر از پیکربندی بزرگ بدون مالک است.
مهاجرت و نگهداری
برای پروژه قدیمی، تعداد و نوع پیام‌ها را ببینید و درباره اولویت تصمیم بگیرید. قواعد مرتبط با خطای محتمل می‌توانند از تغییر سلیقه‌ای قالب مهم‌تر باشند. درباره استثناهای موقت موعد بازبینی بگذارید تا دائمی نشوند. اگر React یا TypeScript اضافه می‌شود، Parser و Plugin مناسب نیاز است؛ نمونه JavaScript ساده این مقاله آن پیکربندی را کامل نمی‌کند. وابستگی معرفی‌نشده را به کد آموزش اضافه نکنید.
در پایان، مسئولیت‌ها را در یک جمله ثبت کنید: Prettier قالب را تعیین می‌کند، ESLint قواعد انتخاب‌شده را بررسی می‌کند و بازبینی انسانی درباره رفتار و طراحی قضاوت می‌کند. هیچ‌کدام جای دیگری را کامل نمی‌گیرد. مجموعه کوچک و قابل توضیح که تیم واقعاً استفاده می‌کند، از فهرست طولانی تنظیمات نامعلوم مناسب‌تر است. هدف، کم‌کردن اصطکاک همکاری و آشکارکردن مسئله‌های قابل خودکارسازی است.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!