ESLint یا Prettier؛ کدام برای کیفیت کد مهم‌تر است؟

ESLint یا Prettier؟ این پرسشی است که در شروع هر پروژه جاوااسکریپت جدی پیش می‌آید. من روی پروژه‌های React، Next.js، Node.js و قالب‌های وردپرسی مدرن با هر دو ابزار کار کرده‌ام و آنچه در ادامه می‌خوانید، تفاوت مفهومی این دو و روش ترکیب درستشان است که در تجربه‌های واقعی بیشترین اثر را داشته.

چارچوب مقایسه: این دو ابزار یک مسئله را حل نمی‌کنند

ESLint و Prettier در نگاه اول مشابه به نظر می‌رسند چون هر دو برای بهبود کیفیت کد جاوااسکریپت استفاده می‌شوند. اما در واقع دو مسئله کاملاً متفاوت را حل می‌کنند. Prettier فقط یک فرمت‌کننده کد (Code Formatter) است؛ وظیفه‌اش مرتب کردن ظاهر کد است: فاصله‌گذاری، شکستن خطوط، پرانتزگذاری، ویرگول‌گذاری. ESLint یک Linter است؛ وظیفه‌اش تحلیل کد و یافتن مشکلات منطقی، الگوهای مشکوک، متغیرهای استفاده‌نشده و مسائل کیفی است.

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

Prettier می‌گوید کد شما چطور نوشته شود؛ ESLint می‌گوید کد شما چه چیزهایی نباید بگوید. این دو مسئله، دو ابزار جدا می‌خواهند.

نقطه اول: ESLint چه می‌کند و چه مشکلاتی را می‌گیرد

ESLint کد شما را تحلیل می‌کند و بر اساس قواعدی که تعریف کرده‌اید، هشدار یا خطا می‌دهد. این قواعد می‌توانند بسیار متنوع باشند: از مسائل پایه مثل متغیر استفاده‌نشده (no-unused-vars) و تابع بازگشتی بدون شرط، تا مسائل پیچیده‌تر مثل اجتناب از حلقۀ اشتباه در کامپوننت React یا هشدار در استفاده نادرست از async/await.

ESLint در پروژه‌های React با پلاگین eslint-plugin-react، در پروژه‌های Next.js با پلاگین رسمی، و در Node.js با پلاگین Node کار می‌کند. این انعطاف، ESLint را به یک ابزار جدی کیفیت تبدیل می‌کند که می‌تواند با نیازهای خاص هر پروژه تنظیم شود.

در تجربه‌های من، ESLint در تیم‌های حرفه‌ای نقش مرکزی دارد. حتی اگر Prettier نصب نباشد، ESLint می‌تواند کیفیت کد را جدی بالا ببرد. در پروژه‌های وردپرسی که با استانداردهای کدنویسی کار می‌کنید، استانداردهای کدنویسی وردپرس را ببینید که چطور ESLint و PHP_CodeSniffer می‌توانند این استانداردها را اعمال کنند.

نکته مهم: ESLint در تنظیمات ساده فقط مسائل پایه را می‌گیرد. هرچقدر قواعد سختگیرانه‌تر باشند، کد شما کیفیت بالاتری خواهد داشت اما زمان بیشتری برای رفع خطاها صرف می‌شود. تعادل درست به سطح پروژه بستگی دارد.

حکم این نقطه: ESLint مسئلۀ منطق و کیفیت کد را حل می‌کند.

نقطه دوم: Prettier چه می‌کند و چطور تعارض را حل می‌کند

Prettier کد شما را بر اساس قواعد استانداردش بازنویسی می‌کند. کاری که انجام می‌دهد این است: ورودی هر کد، خروجی یک فرمت ثابت. عرض خط، نحوه شکستن پرانتز، فاصله بین بلوک‌ها، ترتیب attributeها در JSX و نحوه نوشتن رشته‌ها، همه توسط Prettier تعیین می‌شوند. توسعه‌دهنده دیگر مجبور نیست در جلسه کد ریویو درباره فاصله‌گذاری بحث کند.

مزیت جدی Prettier در این است که بحث‌های بی‌پایان درباره سبک کدنویسی را حل می‌کند. در تیم‌های مختلف، این مسئله همیشه تنش‌زا بوده. Prettier این تنش را حذف می‌کند چون همه به یک شکل واحد کد می‌نویسند.

Prettier فقط جاوااسکریپت را پوشش نمی‌دهد؛ از TypeScript، JSON، CSS، SCSS، HTML، Markdown، YAML و GraphQL پشتیبانی می‌کند. این تنوع باعث شده Prettier به ابزار استاندارد فرمت کردن در پروژه‌های مدرن تبدیل شود. در پروژه‌های وردپرسی که با JSON تنظیمات کار می‌کنید، کار با JSON در پروژه‌های واقعی دید مکملی می‌دهد که چطور Prettier این فایل‌ها را مرتب می‌کند.

حکم این نقطه: Prettier مسئلۀ ظاهر و فرمت یکنواخت کد را حل می‌کند.

نقطه سوم: چرا اکثر تیم‌ها هر دو را با هم استفاده می‌کنند

این مهم‌ترین نکته در این مقایسه است: ESLint و Prettier جانشین یکدیگر نیستند. در واقع ترکیب آنها بیشترین ارزش را ایجاد می‌کند. Prettier مسئول فرمت است و ESLint مسئول کیفیت منطقی. با ترکیب این دو، تیم هم کد مرتب دارد هم باگ‌های منطقی کمتری دارد.

در ده سال اخیر، یک الگوی رایج تثبیت شده: استفاده از eslint-config-prettier برای خاموش کردن قواعد ESLint که با Prettier تعارض دارند. این ترکیب، در پروژه‌های مدرن استاندارد است. برای درک بهتر گردش‌کار تیمی در پروژه‌های توسعه، گیت در وردپرس دید مکملی می‌دهد که چطور pre-commit hook این دو ابزار را اعمال می‌کند.

در تجربه‌های تیمی من، تیم‌هایی که فقط Prettier استفاده می‌کنند، کد مرتب دارند اما باگ‌های منطقی زیاد. تیم‌هایی که فقط ESLint دارند، کد تمیز دارند اما ظاهرش متفاوت است. تیم‌هایی که هر دو را ترکیب می‌کنند، بهترین کیفیت را می‌سازند.

حکم این نقطه: ترکیب ESLint و Prettier استاندارد مدرن است.

نقطه چهارم: پیکربندی درست در پروژه‌های واقعی

پیکربندی درست این دو ابزار در پروژه‌های واقعی، چند نکته کلیدی دارد. اول، فایل eslintrc و .prettierrc باید در مخزن کد باشد تا همه اعضای تیم از همان قواعد استفاده کنند. دوم، باید در git pre-commit hook اجرا شوند تا قبل از commit، کد فرمت و بررسی شود.

سوم، در پروژه‌های TypeScript، پیکربندی باید با typescript-eslint انجام شود. چهارم، در پروژه‌های React، پلاگین‌های eslint-plugin-react و eslint-plugin-react-hooks کمک جدی می‌کنند.

در پروژه‌های وردپرسی که با قالب و افزونه کار می‌کنید، این پیکربندی می‌تواند با استانداردهای وردپرس هم‌راستا شود. برای درک بهتر این استانداردها، استفاده از استانداردهای کدنویسی وردپرس در پروژه‌ها را ببینید.

نکته مهم دیگر: برای CI، این ابزارها باید در pipeline اجرا شوند و اجازه commit بدون پاس شدن کیفیت را ندهند. اگر با CI/CD کار می‌کنید، مقایسه ابزارهای CI/CD دید مکملی می‌دهد که چطور این ابزارها در pipelineها ادغام می‌شوند.

حکم این نقطه: پیکربندی درست در مخزن و CI، کیفیت پایدار می‌سازد.

نقطه پنجم: نقش این ابزار در گردش‌کار تیمی

در تیم‌های حرفه‌ای، ESLint و Prettier فقط ابزار فردی نیستند؛ بخشی از گردش‌کار تیمی محسوب می‌شوند. اگر یک توسعه‌دهنده پیش از commit کردن کد، Prettier اجرا نکند، تفاوت‌های ظاهری در diff ایجاد می‌شود که باعث تعارض‌های بی‌مورد می‌شود.

در تجربه‌های من، تیم‌هایی که Prettier را در pre-commit hook خودکار می‌کنند، diffهای پاک‌تری دارند و بحث‌های کد ریویو روی منطق تمرکز می‌کند نه روی ظاهر. همین موضوع، سرعت review را جدی بالا می‌برد.

در تیم حرفه‌ای، بحث درباره فاصله‌گذاری و سبک کد، وقت تلف کردن است؛ Prettier این بحث را از میان برمی‌دارد تا ذهن تیم روی منطق متمرکز شود.

ESLint در گردش‌کار تیمی، نقش آموزش را هم دارد. وقتی قواعدی مثل no-console در پروژه اعمال می‌شود، توسعه‌دهنده یاد می‌گیرد که console.log در کد تولیدی جای مناسب ندارد. این قواعد، به‌تدریج به عادت تبدیل می‌شوند.

حکم این نقطه: در گردش‌کار تیمی، ترکیب این دو ابزار ضروری است.

در پروژه واقعی چطور تصمیم بگیرم

خبر خوب این است که تصمیم‌گیری بین این دو ابزار مسئله‌ای پیچیده نیست، چون جای هم را نمی‌گیرند. جدول زیر مسیر درست را روشن می‌کند.

در پروژه‌های خودم، هیچ‌وقت یکی از این دو را به‌عنوان تنها ابزار کیفیت انتخاب نمی‌کنم. ترکیب Prettier و ESLint با تنظیمات درست، استاندارد پروژه‌های حرفه‌ای است. اگر روی ساخت API سریع با Node.js و Express کار می‌کنید، همین ترکیب در بک‌اند Node.js هم صادق است. اگر روی Laravel برای توسعه سریع وب کار می‌کنید، Laravel Pint در PHP همان نقش Prettier را دارد و می‌توانید در فرانت‌اند هم ESLint و Prettier را اضافه کنید.

نکته مهم: در پروژه‌های وردپرسی که با افزونه وردپرس کار می‌کنید، ESLint برای بخش جاوااسکریپت و PHP_CodeSniffer برای PHP، پوشش کاملی می‌دهد.

پرسش‌های پرتکرار درباره انتخاب ESLint یا Prettier

آیا ESLint می‌تواند جای Prettier را بگیرد؟ نه به‌طور کامل. ESLint می‌تواند فرمت کند اما این کار را به‌خوبی Prettier انجام نمی‌دهد.

آیا Prettier جای ESLint را می‌گیرد؟ نه. Prettier مسائل منطقی را نمی‌گیرد.

کدام مهم‌تر است؟ اگر فقط یکی را می‌خواهید، ESLint ارزش بیشتری دارد چون مسائل منطقی می‌گیرد. اما استاندارد حرفه‌ای، هر دو است.

چطور از تعارض این دو جلوگیری کنیم؟ با نصب eslint-config-prettier که قواعد متناقض را خاموش می‌کند.

آیا این ابزارها در وردپرس هم کار می‌کنند؟ بله، برای بخش جاوااسکریپت قالب یا افزونه. برای PHP، ابزار جداگانه لازم است.

آیا این ابزارها در CI/CD قابل استفاده‌اند؟ بله و توصیه می‌شود. برای درک بهتر این چرخه، مقایسه GitHub و GitLab را ببینید.

آیا راه‌اندازی این ابزارها در پروژه‌های کوچک توجیه دارد؟ بله، حتی در پروژه‌های کوچک، کد پاکیزه ارزش بلندمدت دارد.

تصمیم نهایی در ابزار کیفیت کد

ESLint یا Prettier؟ این پرسش، پرسش اشتباهی است چون این دو ابزار یک مسئله را حل نمی‌کنند و جانشین هم نیستند. Prettier مسئول ظاهر کد است و ESLint مسئول کیفیت منطقی. ترکیب این دو با تنظیمات درست، استاندارد پروژه‌های حرفه‌ای است. برای درکی تاریخی و دقیق از ESLint، مدخل ESLint در ویکی‌پدیا مفید است. اگر تجربه‌ای از ترکیب این دو در تیم خود داشته‌اید، برای من جالب است بدانید کدام قاعده ESLint بیشترین اثر را روی کیفیت کد شما داشته. 🧹