لینتر ابزاری است که کد را برای مشکلات احتمالی اسکن می کند. این با یک زبان برنامه نویسی مانند جاوا اسکریپت که تایپ بسیار ضعیفی دارد بسیار ارزشمند است.

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

وقتی با استفاده از Next.js CLI ( npx create-next-app ) یک برنامه جدید تولید می کنید، ESLint به طور پیش فرض پیکربندی می شود. اما چندین مشکل در راه اندازی لینتینگ ایجاد شده توسط create-next-app وجود دارد:

اگر SCSS را برای استایل‌سازی انتخاب می‌کنید، باید از Stylelint در فرآیند ساخت برای پرز کردن شیت‌های CSS یا SCSS استفاده کنید. اما به طور خودکار تنظیم نمی شود.

اگر در عوض Tailwind را برای استایل‌سازی انتخاب می‌کنید، باید افزونه Tailwind را برای ESLint راه‌اندازی کنید. اما دوباره، این در پیکربندی ESLint ایجاد شده انجام نمی شود.

اگر TypeScript را انتخاب می‌کنید، در Next.js نسخه 14 و پایین‌تر، قوانین ESLint مخصوص TypeScript پیکربندی نمی‌شوند، برخلاف آنچه در اسناد آمده است . در حالی که یک برنامه Next.js v15 اینها را راه اندازی کرده است، من همچنان تنظیمات را با قوانین پرزبانی قدرتمندتر ارائه شده توسط پروژه typescript-eslint تغییر می دهم.

و در نهایت، Prettier تنظیم نشده است. Prettier یک ابزار قالب بندی کد است. این می تواند از ورود کدهای با فرمت ناسازگار به مخزن کد جلوگیری کند، که مقایسه بین نسخه های مختلف یک فایل را دشوار می کند. همچنین، کار با کدهای با فرمت زیبا آسان تر است. پس این یک حذف بسیار بزرگ است.

در این آموزش، من به شما نشان خواهم داد که چگونه در پروژه های Next.js خود، پرده و قالب بندی را به گونه ای تنظیم کردم که به مشکلات بالا رسیدگی کند. همچنین نحوه نصب و پیکربندی برخی افزونه‌های کد VS مرتبط را برای کمک به کدنویسی به شما آموزش می‌دهم.

برای ادامه، می‌توانید از پروژه Next.js که قبلاً دارید استفاده کنید یا با اجرای npx create-next-app در ترمینال، یک برنامه جدید ایجاد کنید.

اگر در حال ساخت داربست برنامه جدیدی هستید، انتخاب های شما به عهده شماست (پیش فرض ها خوب هستند) اما در پاسخ به این سوال که آیا می خواهید از ESLint استفاده کنید، بله را انتخاب کنید:

که در آن داربست Next.js، Create-Next-app، گزینه های تولید کد را به کاربر نشان می دهد." class="image--center mx-auto" width="688" height="383" loading="lazy">

اگر به جای یک برنامه جدید، یک برنامه موجود را دنبال می کنید، با اجرای دستور زیر در ریشه برنامه، آن را ارتقا دهید:

 npm i next@latest react@latest react-dom@latest eslint-config-next@latest npm i --save-dev eslint

با این کار از تضادهای نسخه‌سازی جلوگیری می‌شود.

اگر نمی‌توانید به آخرین نسخه ارتقا دهید، باید نسخه‌هایی را برای بسته‌هایی که در این آموزش نصب می‌شوند مشخص کنید تا تداخل‌های نسخه را برطرف کنید. هشدار داده شود که این می تواند ناامید کننده باشد.

اکنون آماده هستید تا برنامه را در ویرایشگر کد خود باز کنید و به صورت زیر عمل کنید.

پیش نیازها

من فرض می کنم که شما می دانید چگونه:

یک برنامه اصلی Next.js با دو یا چند صفحه بنویسید.

بسته های NPM اضافی را در برنامه خود نصب کنید

فهرست مطالب

مقدمه

پیش نیازها

فهرست مطالب

زیباتر را تنظیم کنید

یادداشتی در خط پایانی به Prettier

ESLint را راه اندازی کنید

اصول اولیه پیکربندی ESLint

راه اندازی ESLint برای TypeScript

راه اندازی ESLint برای Tailwind

راه اندازی ESLint برای زیباتر

Stylelint را تنظیم کنید

اسکریپت های package.json را تنظیم کنید

راه اندازی lint-staged

راه‌اندازی برنامه‌های گفت نی کد در مقابل

بررسی نهایی و عیب یابی

نتیجه گیری

زیباتر را تنظیم کنید

Prettier یک فرمت‌کننده کد است که می‌تواند تقریباً هر فایلی را قالب‌بندی کند ( .html ، .json ، .js ، .ts ، .css ، .scss و غیره).

آن را در برنامه yuor به صورت زیر تنظیم کنید:

Prettier را نصب کنید:

 npm install --save-dev prettier

اگر هنگام ایجاد برنامه، Tailwind را برای استایل‌سازی انتخاب کرده‌اید، prettier-plugin-tailwindcss را نصب کنید:

 npm install --save-dev prettier-plugin-tailwindcss

این بسته یک پلاگین Prettier است و قوانینی را برای مرتب سازی مجدد کلاس های Tailwind که در یک class یا ویژگی className بر اساس ترتیب متعارف استفاده می شود، ارائه می دهد. این کمک می کند تا مرتب سازی کلاس های Tailwind که در نشانه گذاری استفاده می شود ثابت بماند.

%[https://youtu.be/tQkBJXwzY8A?autoplay=1]

.prettierrc.json را در ریشه پروژه youyr ایجاد کنید. اگر از SCSS برای استایل‌سازی استفاده می‌کنید، قطعه زیر را در این فایل قرار دهید:

 { "singleQuote" : true , "jsxSingleQuote" : true }

اگر به جای آن از Tailwind استفاده می کنید، موارد زیر را در .prettierrc.json قرار دهید:

 { "plugins" : [ "prettier-plugin-tailwindcss" ], "singleQuote" : true , "jsxSingleQuote" : true }

فایل .prettierignore را در ریشه برنامه با محتوای زیر ایجاد کنید:

 node_modules .next .husky coverage .prettierignore .stylelintignore .eslintignore stories storybook-static *.log playwright-report .nyc_output test-results junit.xml docs

این فایل تضمین می‌کند که فایل‌هایی که کد برنامه نیستند (یعنی آنهایی که فایل‌های .js ، .ts ، .css و غیره نیستند.) فرمت نمی‌شوند. در غیر این صورت زیباتر زمان زیادی را صرف پردازش فایل‌هایی می‌کند که قالب‌بندی آنها واقعاً برای شما مهم نیست.

'prettierignore (فایلی که به تازگی ایجاد کردیم)، .eslintignore و .stylelintignore نادیده گرفته شده اند زیرا اینها فایل های متنی ساده و بدون ساختار هستند پس زیباتر شکایت می کند که نمی تواند آنها را قالب بندی کند.

در نهایت، توصیه می‌کنم برای تنظیم LF به عنوان کاراکتر EOL، چه در مخزن و چه در تنظیمات VS Code، مراحل این پست را دنبال کنید. دلیل این امر در زیر بخش زیر آورده شده است.

یادداشتی در خط پایانی به Prettier

Prettier به طور پیش‌فرض LF (نویسه تغذیه خط) را برای انتهای خطوط در نظر گرفته است . این به این معنی است که وقتی فایل‌ها را فرمت می‌کند، تمام رخدادهای دنباله کاراکتر CRLF را، در صورت وجود، به LF تغییر می‌دهد.

LF همچنین پیش فرض در ویرایشگرهای متن و سایر ابزارها در سیستم های مبتنی بر یونیکس (لینوکس، MacOS و غیره) است. اما در ویندوز، پیش‌فرض پایان‌های خطوط، CRLF (نویسه بازگشت حمل و به دنبال آن کاراکتر Line Feed) است.

ابزارهای ویندوز مانند ویرایشگرهای متن و کد می توانند به راحتی LF را به عنوان پایان خط کنترل کنند. اما CRLF می تواند برای ابزارهای سیستم های مبتنی بر یونیکس مانند لینوکس و انواع مختلف یونیکس مشکل ساز باشد. پس منطقی است که فقط از LF به عنوان انتهای خط در کد استفاده کنید زیرا این کار در سیستم های مبتنی بر ویندوز و یونیکس کار می کند.

پیکربندی LF به عنوان کاراکتر EOF در Git repo و در ویرایشگرهای کد، ابزار شما را با پیش‌فرض Prettier مطابقت می‌دهد. همچنین اطمینان حاصل می کند که تمام فایل های موجود در مخزن Git به طور مداوم دارای انتهای خط LF هستند. پس ، اگر یک مشارکت‌کننده در مخزن شما در ویندوز باشد که از CRLF به عنوان کاراکتر EOL استفاده می‌کند، کدی که در مخزن اضافه یا تغییر می‌دهد همچنان از LF استفاده می‌کند: ویرایشگر کد فایل‌های کد جدید را به‌طور پیش‌فرض به LF می‌دهد. git commit در هنگام commit کردن هر CRLF را به LF تبدیل می کند.

در نهایت، تنظیم LF به عنوان انتهای خط برای کل مخزن، از اتفاقات عجیبی که در ویندوز رخ می دهد، جلوگیری می کند، Prettier پیش فرض LF خود را حفظ می کند، اما Git و ویرایشگر کد شما همچنان از CRLF پیش فرض خود برای پایان خطوط استفاده می کنند:

هنگامی که پسوند VS Code Prettier یک فایل را قالب بندی می کند (به عنوان مثال، هنگامی که پسوند به صورت "قالب خودکار در ذخیره" تنظیم شده است)، انتهای خطوط CRLF را تغییر نمی دهد. اما فرمت کردن همان فایل با اجرای Prettier در خط فرمان ، انتهای خطوط را به LF تغییر می‌دهد . این اختلاف می تواند آزاردهنده باشد.

هنگام اجرای git add . :

که با دستور git add نشان داده می‌شوند زمانی که برخی از فایل‌های اضافه شده حاوی LF هستند اما خط پیش‌فرض پایان خط مخزن CRLF است. " class="image--center mx-auto" width="800" height="78" loading="lazy">

ESLint را راه اندازی کنید

اصول اولیه پیکربندی ESLint

ESLint با تعدادی از قوانین پرزدار خارج از جعبه ارائه می شود. اما شما همچنین می توانید آنها را با افزونه های ESLint تکمیل کنید.

یک پلاگین ESLint برخی از قوانین linting را تعریف می کند. به عنوان مثال، اگر درمخزن GitHub برای افزونه Next's ESLint ، eslint-plugin-next، نگاه کنید، هر فایل در پوشه src/rules یک قانون linting را به عنوان یک تابع TypeScript تعریف می کند. سپس index.js بسته این توابع قانون را در شیء rules در صادرات پیش‌فرض خود صادر می‌کند:

 module . exports = { rules: { 'google-font-display' : require ( './rules/google-font-display' ), 'google-font-preconnect' : require ( './rules/google-font-preconnect' ), 'inline-script-id' : require ( './rules/inline-script-id' ), ...

راه اصلی برای استفاده از این قوانین در برنامه شما این است که بسته افزونه را نصب کنید، سپس آن را در فایل پیکربندی ESLint در پوشه اصلی برنامه ارجاع دهید.

برای مثال، می‌توانیم با اجرای npm install --save-dev eslint-plugin-next eslint-plugin-next -next استفاده کنیم و سپس محتوای زیر را در فایل پیکربندی ESLint .eslintrc.json در ریشه برنامه قرار دهیم:

 { plugins: [ "next" ], "rules" : { "google-font-display" : "warning" , "google-font-preconnect" : "warning" , "inline-script-id" : "error" , } }

اگر اکنون npx eslint . در پوشه اصلی برنامه شما، ESLint هر فایل جاوا اسکریپت در برنامه را در برابر هر یک از سه قانون پیکربندی شده در بالا پر می کند.

هنگام پیکربندی یک قانون برای استفاده، می‌توانید سه شدت را به آن اختصاص دهید: off ، warning و error . همانطور که قطعه بالا نشان می دهد، یک قانون را با اختصاص دادن یک warning یا error در .eslintrc.json برنامه به آن فعال می کنید.

هنگامی که به یک افزونه در فایل پیکربندی ESLint برنامه خود ارجاع می دهید، پیشوند eslint-plugin- در نام بسته افزونه حذف می شود. به همین دلیل است که بسته ای که حاوی قوانین linting برای Next.js، eslint-plugin-next ، فقط به عنوان "next" در قطعه بالا ارجاع داده می شود.

از آنجایی که پیکربندی یک سطح شدت - off ، warning یا error - برای هر قانون منفرد از هر افزونه ای که می خواهید استفاده کنید بسیار دشوار است، هنجار این است که به یک شی پیکربندی ESLint یا به اختصار پیکربندی ESLint اشاره کنید که توسط آن صادر می شود. یک بسته NPM این یک شی جاوا اسکریپت است که افزونه‌ها را اعلام می‌کند و قوانین را با سطوح شدت پیکربندی می‌کند، همانطور که در بالا انجام دادیم.

برای مثال، صادرات پیش‌فرض از eslint-plugin-next نیز شامل چندین پیکربندی ESLint است. در اینجا یک قطعه دیگر از index.js از افزونه است که این بار تنظیمات ESLint صادر شده را علاوه بر شی rules برای صادرات توابع قانون نشان می دهد:

 module . exports = { rules: { 'google-font-display' : require ( './rules/google-font-display' ), 'google-font-preconnect' : require ( './rules/google-font-preconnect' ), 'inline-script-id' : require ( './rules/inline-script-id' ), ... }, configs: { recommended: { plugins: [ '@next/next' ], rules: { // warnings '@next/next/google-font-display' : 'warn' , '@next/next/google-font-preconnect' : 'warn' , ... // errors '@next/next/inline-script-id' : 'error' , '@next/next/no-assign-module-variable' : 'error' ... } }, 'core-web-vitals' : { plugins: [ '@next/next' ], extends : [ 'plugin:@next/next/recommended' ], rules: { '@next/next/no-html-link-for-pages' : 'error' , '@next/next/no-sync-scripts' : 'error' , }, }, }

همانطور که می بینید، علاوه بر قوانین (بسیار بیشتر از موارد نشان داده شده در بالا وجود دارد)، افزونه دو پیکربندی - recommended و core-web-vitals - را نیز صادر می کند که انتخاب های مختلفی از قوانین تعریف شده در افزونه را با تعیین شدت فعال می کند. سطوح error یا warning به آنها.

پیکربندی که معمولاً در پروژه‌های Next.js استفاده می‌شود، core-web-vitals است. ما می‌توانیم از این شی پیکربندی در فایل پیکربندی ESLint برنامه خود ( .eslintrc.json در ریشه برنامه) به صورت زیر استفاده کنیم:

 { "extends" : [ "plugin:next/core-web-vitals" ] }

پس بسیار ساده‌تر از این است که افزونه را در plugins شیء اعلام کنیم و سپس به هر قانون از افزونه‌ای که می‌خواهیم استفاده کنیم، یک سطح شدت error یا warning نسبت دهیم.

به تفاوت بین فایل پیکربندی - این .eslintrc.json است - و پیکربندی توجه کنید - این شیئی است که برخی از قوانین را از یک افزونه برای استفاده در پروژه مشتری با اختصاص دادن شدت به قوانین انتخاب شده پیکربندی می کند.

محتویات فایل پیکربندی خود یک پیکربندی هستند. اما در فایل‌های پیکربندی، ما معمولاً افزونه‌ای را وارد نمی‌کنیم و تمام قوانینی را که می‌خواهیم از آن استفاده کنیم، پیکربندی می‌کنیم. در عوض، ما تقریباً همیشه یک شی پیکربندی شناخته شده/معتمد را وارد می کنیم که توسط یک بسته NPM صادر می شود. چنین شی پیکربندی - موردی که توسط یک بسته NPM برای استفاده در فایل های پیکربندی ESLint (در سایر بسته ها/برنامه ها) صادر می شود - به عنوان پیکربندی قابل اشتراک گذاری نیز شناخته می شود.

به طور معمول، پلاگین ها - قوانین ESLint را به عنوان توابع جاوا اسکریپت/تایپ اسکریپت تعریف می کنند - همچنین قوانین خود را در یک یا چند پیکربندی قابل اشتراک گذاری دسته بندی می کنند. پیکربندی recommended از افزونه eslint-plugin-next که در بالا استفاده کردیم، تنها یکی از این تنظیمات است.

پیکربندی‌های قابل اشتراک‌گذاری تنها از بسته‌های افزونه نمی‌آیند، اگرچه مرسوم است که افزونه‌ها یک یا چند پیکربندی قابل اشتراک‌گذاری متشکل از قوانین خودشان را صادر می‌کنند. بسته‌های دیگر که نام آنها با eslint-config- شروع می‌شود (برخلاف eslint-plugin- ) می‌توانند یک یا چند پیکربندی نام‌گذاری شده را ارائه دهند.

Next.js چنین بسته ای به نام eslint-config-next را ارائه می دهد. این تنظیمات پیکربندی های recommended و core-web-vitals از افزونه دوباره صادر می کند. همچنین یک پیکربندی از قوانین linting TypeScript را از افزونه typescript-eslint/eslint-plugin مجددا صادر می کند (در نسخه 15 و بالاتر از بسته). پس به جای استفاده از تنظیمات recommended از افزونه مانند آنچه در بالا انجام دادیم:

 { "extends" : [ "plugin:next/core-web-vitals" ] }

می توانستیم بسته eslint-config-next را نصب کنیم و از آن در .eslintrc.json استفاده کنیم:

 { "extends" : [ "next/core-web-vitals" ] }

از آنجایی که نام بسته با plugin: نیست، ESLint آن را یک بسته پیکربندی می‌داند و نام آن را به‌عنوان eslint-config-next به جای eslint-plugin-next بازسازی می‌کند. توجه داشته باشید که چگونه با بسته های پیکربندی، پیشوند متعارف eslint-config- هنگام ارجاع به آن در فایل پیکربندی ESLint حذف می کنیم.

امکان ارجاع چندین پیکربندی قابل اشتراک گذاری در extends وجود دارد. در این مورد، تمام قوانین از همه پیکربندی ها استفاده می شود - به جز مواردی که چندین پیکربندی وجود دارد که هر کدام یک قانون با نام یکسان ارائه می دهند. در این مورد آخرین پیکربندی، از چپ به راست، برنده می شود. این بدان معناست که در جایی که تضاد نامگذاری وجود دارد، ESLint از قانون آخرین پیکربندی موجود در فهرست استفاده می کند.

امکان استفاده از فرمت های فایل پیکربندی ESLint به غیر از JSON وجود دارد. به جای آن می‌توانید همان اطلاعات موجود در فایل .eslintrc.json را در فایل جاوا اسکریپت ( .eslintrc.js یا .eslintrc.cjs ) یا yaml ( .eslintrc.yml یا .eslintrc.yaml ) ارائه دهید.

همچنین، ESLint یک فرمت فایل پیکربندی جدید دارد که اغلب به آن flat config می‌گویند (که من در اینجا از آن استفاده نکرده‌ام) که در آن فایل‌های پیکربندی یا JavaScript یا TypeScript هستند.

با آگاهی از نحوه پیکربندی ESLint برای استفاده، آماده راه اندازی ESLint در پروژه Next.js خود هستید. بخش های زیر به شما نشان می دهد که چگونه این کار را انجام دهید.

راه اندازی ESLint برای TypeScript

اگر برنامه شما از TypeScript استفاده می کند ، فایل پیکربندی ESLint (.esilntrc.json) را به صورت زیر تغییر دهید:

در ترمینال، در پوشه root برنامه، دستور زیر را اجرا کنید:

 npm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin typescript

@typescript-eslint/eslint-plugin تعدادی قواعد لینتینگ برای فایل‌های TypeScript و همچنین پیکربندی‌های قابل اشتراک‌گذاری ارائه می‌کند که بررسی‌هایی را که کامپایلر TypeScript انجام می‌دهد تقویت می‌کند.

@typescript-eslint/parser تجزیه‌کننده‌ای است که به ESLint اجازه می‌دهد فایل‌های TypeScript را تجزیه کند (به طور پیش‌فرض فقط می‌تواند فایل‌های جاوا اسکریپت را تجزیه کند).

من کامپایلر TypeScript را به عنوان یک بسته - typescript - اضافه می کنم زیرا دستورالعمل های typescript-eslint Getting Started همین کار را می کند.

در پوشه ریشه برنامه، .eslintrc.json را به .eslintrc.js تغییر نام دهید. سپس محتوای .eslintrc.js را در ریشه برنامه با موارد زیر جایگزین کنید:

 /* eslint-env node */ module .exports = { root : true , extends : [ 'next/core-web-vitals' , ], plugins : [ '@typescript-eslint' , 'tailwindcss' ], parser : '@typescript-eslint/parser' , overrides : [ { files : [ '*.ts' , '*.tsx' ], parserOptions : { project : [ './tsconfig.json' ], projectService : true , tsconfigRootDir : __dirname, }, extends : [ 'next/core-web-vitals' , 'plugin:@typescript-eslint/recommended' , //'plugin:@typescript-eslint/recommended-type-checked', // 'plugin:@typescript-eslint/strict-type-checked', // 'plugin:@typescript-eslint/stylistic-type-checked', ] }, ], };

این کاری است که خطوط مختلف این فایل انجام می دهند :

/* eslint-env node */ مانع از شکایت ESLint می‌شود که این ماژول CommonJS است. ما مجبور شدیم این را وارد کنیم زیرا ESLint، همانطور که آن را در اینجا پیکربندی کرده ایم، به ماژول های CommonJS اجازه نمی دهد (که .eslintrc.js است، به module.exports = ... در بالا مراجعه کنید) و انتظار دارد که ماژول ها در پروژه باشند. ES6.

root: true می گوید که این بالاترین فایل پیکربندی ESLint است حتی اگر ممکن است تنظیمات ESLint تو در تو در زیر پوشه ها وجود داشته باشد.

extends: پیکربندی های مختلف ESLint را مشخص می کند که هر کدام مجموعه ای از قوانین linting را فعال می کند.

'next/core-web-vitals' پیکربندی ارائه شده توسط eslint-config-next است که قوانین خاص Next.js را (هم برای جاوا اسکریپت و هم برای TypeScript، از بازرسی کد آن در GitHub) باندل می کند.

پیکربندی recommended-type-checked (که در یک extends تودرتو در شیء overrides استفاده می‌شود - این به‌زودی توضیح داده می‌شود) توسط @typescript-eslint/eslint-plugin ارائه شده است. این افزونه بخشی از پروژه typescript-eslint است که بسته هایی را برای قوانین لینتینگ و تجزیه کننده ها منتشر می کند تا از لینتینگ فایل های TypeScript توسط ESLint پشتیبانی کند.

تنظیمات مورد استفاده در اینجا توضیح داده شده است. این یک مجموعه فوق العاده از نسخه های غیر تایپ تحلیل شده پیکربندی است recommended . این قوانین لنتینگ را اضافه می کند که از API تحلیل نوع TypeScript برای اطلاعات نوع اضافی استفاده می کند. این قوانین قدرتمندتر از آنهایی هستند که در پیکربندی recommended پایه و بدون تحلیل تایپ وجود دارد که فقط به تجزیه کننده ESLint برای TypeScript متکی هستند - package @typescript-eslint/parser .

ممکن است ترجیح دهید از پیکربندی‌های علامت‌گذاری strict-type-checked و stylistic-type-checked ، که توسط @typescript-eslint/eslint-plugin نیز ارائه شده‌اند، استفاده کنید. اینها سختگیرتر از آنچه من استفاده کرده ام است.

سخت‌ترین انتخاب برای پرده‌بندی TypeScript احتمالاً پیکربندی recommended است. این همان چیزی است که توسط eslint-plugin-next به‌عنوان پیکربندی با نام typescript دوباره صادر می‌شود و در دستورالعمل‌های Next.js برای راه‌اندازی ESLint با TypeScript به‌عنوان next/typescript (حداقل تا زمان نگارش این مقاله، سپتامبر 2024) ارجاع داده می‌شود. من تنظیماتی را که به جای آن استفاده کرده ام ترجیح می دهم.

parser: '@typescript-eslint/parser' تجزیه کننده ESLint TypeScript را مشخص می کند که به جای تجزیه کننده پیش فرض Espree که نمی تواند فایل های TypeScript را تجزیه کند استفاده شود.

parserOptions: به تجزیه کننده می گوید که کجا فایل tsconfig.json را پیدا کند. این اطلاعات به قوانین موجود در پیکربندی نوع چک شده استفاده شده در بالا - recommended-type-checked - اجازه می دهد تا از API های تحلیل نوع TypeScript استفاده کنند.

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

plugins: ['@typescript-eslint'] : من نمی دانم هدف از این خط چیست. لازم نیست و من آزمایش کرده ام که پیکربندی ESLint داده شده بدون آن به خوبی کار می کند. اما هیچ ضرری ندارد و در یک مثال در اسناد افزونه وجود داشت که من پیکربندی فوق را از آن اقتباس کردم. پس من آن را نگه داشته ام.

بخش overrides تضمین می‌کند که گزینه‌های تجزیه‌کننده TypeScript که باید برای پشتیبانی از تنظیمات نوع تحلیل شده پیکربندی می‌کردیم، فقط برای پسوندهای .ts و .tsx اعمال می‌شوند (از این پاسخ عالی StackOverflow ). در غیر این صورت، اگر اشیاء parser و parserOptions در سطح بالایی بودند، اجرای ESLint روی پروژه باعث ایجاد خطا در فایل‌های .js می‌شود.

این یک مشکل است زیرا ما چندین فایل پیکربندی .js از جمله خود .eslintrc.js داریم، پس خطاهای پرده ای وجود خواهد داشت. ما می توانیم با استفاده از override از این خطاها جلوگیری کنیم.

راه اندازی ESLint برای Tailwind

اگر برنامه شما از Tailwind استفاده می کند، پیکربندی را به صورت زیر تغییر دهید:

در ترمینال، در پوشه ریشه برنامه، npm install --save-dev eslint-plugin-tailwindcss را اجرا کنید.

در پیکربندی ESLint، "plugin:tailwindcss/recommended" را به انتهای extends اضافه کنید:

 { "extends" : [ "next/core-web-vitals" , ..., "plugin:tailwindcss/recommended" ], }

در پیکربندی ESLint، "tailwindcss" را به plugins اضافه کنید و یک شی rules را مانند شکل زیر اضافه کنید:

 { "plugins" : [..., "tailwindcss" ], "rules" : { "tailwindcss/classnames-order" : "off" }, }

اگر برنامه شما از TYPESCRIPT استفاده می‌کند، سپس "plugin:tailwindcss/recommended" را نیز به extends داخلی در overrides اضافه کنید و شی rules در داخل overrides کپی کنید:

 { ... overrides: [ { extends : [ "next/core-web-vitals" , ..., "plugin:tailwindcss/recommended" ], rules : { 'tailwindcss/classnames-order' : 'off' , }, } }

در مراحل راه‌اندازی Tailwind در بالا، ما بسته پلاگین ESLint برای Tailwind، eslint-plugin-tailwindcss نصب کرده‌ایم و از پیکربندی recommended ارائه شده توسط افزونه استفاده کرده‌ایم.

eslint-plugin-tailwind قوانین مفیدی را برای کلاس‌های Tailwind CSS که در نشانه‌گذاری HTML یا JSX/TSX استفاده می‌شوند، ارائه می‌کند. بزرگترین مورد برای من این است که اگر کلاس مورد استفاده در کد یک کلاس Tailwind نباشد، یک خطای linting وجود دارد. این منطقی است زیرا وقتی از Tailwind استفاده می کنم، فقط از کلاس های تولید شده توسط Tailwind استفاده می کنم و کلاس های CSS خودم را تعریف نمی کنم.

این افزونه همچنین قانونی دارد که تحلیل می‌کند دنباله‌ای از نام‌های کلاس Tailwind که در ویژگی class یا className در نشانه‌گذاری استفاده می‌شوند، از ترتیب متعارفی پیروی می‌کنند. اما ما prettier-plugin-tailwindcss را در پیکربندی Prettier خود نصب کردیم که در بالای آن نام کلاس های Tailwind را نیز مرتب می کند. پس ما به این قانون در ESLint نیاز نداریم و ممکن است با کاری که Prettier در گردش کار ما انجام می دهد در تضاد باشد.

ما این قانون را که tailwindcss/classnames-order نامیده می‌شود، در پیکربندی بالا با اعلان شیء افزونه در plugins ، و سپس تنظیم قانون در off در شیء rules ، خاموش می‌کنیم.

راه اندازی ESLint برای زیباتر

در ترمینال اجرا:

 npm install --save-dev eslint-config-prettier

در پیکربندی ESLint، "prettier" به انتهای extends اضافه کنید:

 { "extends" : [ "next/core-web-vitals" , ..., "prettier" ] }

اگر برنامه شما از TypeScript استفاده می‌کند ، سپس "plugin:tailwindcss/recommended" overrides نیز به extends داخلی اضافه کنید:

 { ... overrides: [ { "extends" : [ "next/core-web-vitals" , ..., "prettier" ], } }

در مراحل تنظیم Prettier در بالا، پیکربندی به عنوان prettier نام بسته NPM eslint-config-prettier با eslint-config- deleted است. صادرات پیش‌فرض از بسته یک شی پیکربندی کامل ESLint است و این پیکربندی است که می‌خواهیم استفاده کنیم.

پس در این مورد، همانطور که در هنگام ارجاع به پیکربندی نامگذاری شده core-web-vitals از بسته eslint-config-next که به عنوان next/core-web-vitals ارجاع دادیم، نام prettier را با /<name of config> پسوند نمی کنیم. next/core-web-vitals (به مرحله 1 در بالا مراجعه کنید).

این پیکربندی قوانینی را در ESLint که با قالب بندی کد انجام شده توسط Prettier در تضاد هستند، خاموش می کند. این باید آخرین پیکربندی در extends باشد.

.eslintignore در ریشه پروژه ایجاد کنید. فعلاً نیازی به داشتن محتوایی ندارد، اما اگر نیاز به اضافه کردن پوشه‌ها یا فایل‌هایی داشته باشید که باید توسط ESLint نادیده گرفته شوند، در آینده مفید خواهد بود (برای نمونه به بخش آخر این پست مراجعه کنید).

Stylelint را تنظیم کنید

Stylelint یک لیتر برای شیوه نامه های CSS و SCSS است.

اگر از SCSS و NOT Tailwind استفاده می‌کنید، با دنبال کردن دستورالعمل‌های زیر، Stylelint را راه‌اندازی کنید. این تنظیم برای هر دو فایل CSS و SCSS کار خواهد کرد:

در ترمینال در root پروژه این دستور را اجرا کنید:

 npm install --save-dev sass

Next.js دارای پشتیبانی داخلی SASS/SCSS است ( پس پیکربندی Webpack می داند چگونه فایل های .scss و .sass را مدیریت کند). اما همچنان باید خودتان نسخه ای از بسته sass را نصب کنید، کاری که در بالا انجام دادیم.

در مرحله بعد، بسته هایی را برای Stylelint و تنظیمات قانون آن نصب کنید:

 npm install --save-dev stylelint stylelint-config-standard-scss stylelint-config-prettier-scss

از این سه بسته:

stylelint لینتر است.

stylelint-config-standard-scss یک پیکربندی Stylelint است که قوانین لینتینگ را ارائه می کند. از پلاگین Stylelint stylelint-css استفاده می کند و تنظیمات stylelint-config-standard را که قوانین را برای وانیلی CSS تعریف می کند، و stylelint-config-recommended-scss را که قوانین خاص SCSS را تعریف می کند، گسترش می دهد. در نتیجه، گسترش از این یک پیکربندی برای دریافت پشتیبانی از linting برای هر دو فایل CSS و SCSS کافی است.

stylelint-config-prettier-scss stylelint-config-prettier را گسترش می دهد و آن دسته از قوانین Stylint را که با قالب بندی کد Prettier در تضاد هستند خاموش می کند. آرایه در .stylelintrc.json باید آخرین را در extends: اعلان کرد (مانند شکل زیر).

حال، .stylelintrc.json در ریشه پروژه با محتوای زیر ایجاد کنید:

 { "extends" : [ "stylelint-config-standard-scss" , "stylelint-config-prettier-scss" ], "rules" : { "selector-class-pattern" : null } }

بخش "extends" دو پیکربندی Stylelint را که بسته های NPM آنها را در مرحله قبل نصب کردیم، اعلام می کند.

بخش "rules" برای پیکربندی قوانین stylints استفاده می شود. در اینجا می‌توانید قوانین Stylinint را روشن یا خاموش کنید یا رفتار آن‌ها را پیکربندی کنید.

شما می توانید یک قانون را با تنظیم آن بر روی null خاموش کنید، همانطور که من برای "selector-class-pattern" انجام دادم. من آن را خاموش کردم زیرا اصرار دارد که کلاس‌های CSS را در کیس کباب داشته باشد (به عنوان مثال، .panel-quiz به جای .panelQuiz ). به دلایل مختلف آن را ناخوشایند می دانم، پس آن را خاموش کردم.

سپس، .stylelintignore را در ریشه پروژه با محتوای زیر ایجاد کنید:

 styles/globals.css styles/Home.module.css coverage

من این فایل را ایجاد کردم تا دو شیوه نامه تولید شده توسط Next.js CLI که با قوانین پرده سازی مطابقت ندارند نادیده گرفته شوند (ممکن است راه بهتری برای انجام این کار وجود داشته باشد اما این برای من کار می کند). همچنین، فایل‌های موجود در پوشه coverage نیازی به پرده شدن ندارند و احتمالاً خطاهایی ایجاد می‌کنند.

اسکریپت های package.json را تنظیم کنید

مهمترین اسکریپت "build" است. دستور پیش‌فرض این اسکریپت، next build ، ESLint را اجرا می‌کند اما زیباتر یا (اگر از SCSS استفاده می‌کنید) Styelint را اجرا می‌کند. پس آن را در فایل package.json به صورت زیر تغییر دهید:

اگر برنامه شما از Tailwind استفاده می کند، پس:

 { "scripts" : { "build" : "prettier --check . && next build" , ...

در غیر این صورت، اگر برنامه شما از SCSS استفاده می کند، پس:

 { "scripts" : { "build" : "prettier --check . && stylelint --allow-empty-input \"**/*.{css,scss}\" && next build" , ...

با این ترفند در اسکریپت build موجود، می‌توانیم npm run build به صورت محلی یا در خط لوله CI/CD اجرا کنیم و نه تنها در صورت خرابی ESLint (این مورد قبلاً بود) بلکه در قالب‌بندی زیباتر یا شکست Stylelint نیز با شکست مواجه می‌شود.

در واقع اگر برنامه خود را در Vercel مستقر کنید ، خط لوله پیش‌فرض آنجا نیز npm run build فراخوانی می‌کند. پس وقتی خطایی را در یکی از شیوه نامه های خود معرفی کردم، سپس در Vercel مستقر شدم، در حین استقرار با خطای Stylelint زیر مواجه شدم:

توجه داشته باشید که من از علامت --check با prettier در اسکریپت استفاده کردم (یعنی از دستور prettier --check . ) استفاده کردم. این گزینه Prettier را در حالت تحلیل اجرا می کند، پس فقط قالب بندی صحیح را تحلیل می کند و قالب بندی را تغییر نمی دهد.

من این کار را انجام دادم زیرا اسکریپت build همان چیزی است که خط لوله استقرار Vercel به طور پیش‌فرض برای ساخت کد فراخوانی می‌کند، و من نمی‌خواهم قالب‌بندی در طول ساخت CI تغییر کند (و نه می‌خواهم با پیش‌فرض‌های Vercel دستکاری کنم، مگر اینکه کاملاً مجبور باشم).

برای اجرای Prettier به صورت محلی برای قالب‌بندی واقعی پایگاه کد، یک اسکریپت build:local جداگانه تعریف می‌کنم که همان build است اما Prettier را بدون علامت --check اجرا می‌کند، همچنین یک اسکریپت format جداگانه فقط برای قالب‌بندی با Prettier (اما نه build) . اینها در زیر تنظیم شده اند.

اسکریپت "format" را در package.json خود تنظیم کنید. این پایگاه کد را با Prettier فرمت می‌کند و هرازگاهی به کارتان می‌آید:

 { "scripts" : { ... "format" : "prettier --write ."

من توصیه می کنم یک اسکریپت build:local را به صورت زیر تنظیم کنید:

اگر برنامه شما از Tailwind استفاده می کند، پس:

 "build:local" : "prettier --write . && next build"

در غیر این صورت، اگر برنامه شما از SCSS استفاده می کند، پس:

 "build:local" : "prettier --write . && stylelint --allow-empty-input \"**/*.{css,scss}\" && next build"

از آنجایی که نمی‌توانیم قبل از اجرای next build در اسکریپت build موجود، کد را با Prettier قالب‌بندی کنیم (به دلایلی که در بالا توضیح داده شد)، می‌توانیم از این اسکریپت به صورت محلی برای قالب‌بندی کد و سپس پر کردن و ساخت یکباره استفاده کنیم.

راه اندازی lint-staged

lint-staged بسته‌ای است که می‌توانید از آن برای اجرای دستورات قالب‌بندی و linting روی فایل‌های مرحله‌ای در یک مخزن Git استفاده کنید. فایل های مرحله بندی شده آنهایی هستند که با استفاده از git add . . اینها فایل هایی هستند که از آخرین commit تغییر کرده اند و با اجرای بعدی git commit متعهد خواهند شد.

Husky انتخاب معمولی در بسته‌های Node.js برای ثبت دستورات برای اجرا در قلاب‌های Git است. به عنوان مثال، ثبت دستور npx lint-staged با هاسکی برای اجرا در قلاب پیش commit Git به این معنی است که هر زمان که git commit اجرا کنید، lint-staged به طور خودکار اجرا می شود.

در آن زمان، قالب‌کننده (Prettier) و لینترها (ESLint یا Stylelint) که برای اجرا در فایل پیکربندی lint-staged پیکربندی شده‌اند، روی فایل‌های مرحله‌بندی شده اجرا می‌شوند. اگر در حین تحلیل قالب‌بندی یا خط‌بندی خطایی وجود داشته باشد، commit ناموفق خواهد بود.

هر زمان که git commit به دلیل خطاهای linting ناموفق بود، می‌توانیم آن‌ها را برطرف کنیم، سپس git add . و دوباره git commit . پس کد تنها زمانی وارد مخزن می‌شود که به‌طور مداوم قالب‌بندی و تأیید شود که خطای پرده‌ای ندارد. این به ویژه در یک محیط تیمی سودمند است.

من ترجیح می دهم فقط prettier --check . روی فایل های مرحله بندی شده به طور خاص، من به دلایل زیر قالب بندی فایل های مرحله بندی شده را تغییر نمی دهم و در طول یک commit پر نمی کنم:

دلیل قالب‌بندی نکردن کد: من تقریباً همیشه کدم را قبل از انجام کار می‌سازم و آزمایش می‌کنم. هر قالب بندی کد باید قبل یا در طول این ساخت و آزمایش محلی اتفاق افتاده باشد.

به نظر من این ایده که کدی که وارد مخزن من می‌شود باید به‌طور خودکار تغییر کند، درست همانطور که بعد از اینکه مطمئن شدم هرگونه تغییر کد خوب است، کمی غیرجذاب است، تغییر کند.

دلیل عدم چاپ کد: با کد تایپ اسکریپت، کامپایلر می تواند تعداد زیادی مشکل را در کد پیدا کند. قوانین linting اضافی ارائه شده توسط eslint-typescript/eslint-plugin فقط تکمیل کننده تحلیل های انجام شده توسط کامپایلر TypeScript است . پس اگر در زمان commit کد را در فایل‌های مرحله‌ای قرار می‌دهم، باید آن را نیز بسازم (به طوری که کامپایلر TypeScript اجرا شود).

اما ساختن بر روی یک کد بزرگ می تواند بسیار وقت گیر باشد. علاوه بر این، من تقریباً همیشه می‌سازم و آزمایش می‌کنم (به دلیل نحوه تنظیم اسکریپت‌ها در package.json در بالا). به همین دلیل، نیازی به تکرار فرآیند لینت و بیلد روی فایل های مرحله بندی شده احساس نمی کنم.

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

پس اکنون، lint-staged و Husky را به صورت زیر تنظیم کنید:

بسته lint-stageed را نصب کنید:

 npm install --save-dev lint-staged

lint-staged.config.js در ریشه پروژه با محتویات زیر ایجاد کنید:

 /* eslint-env node */ const path = require ( 'path' ); const formatCommand = 'prettier . --check' ; module .exports = { '*' : formatCommand, };

بسته Husky NPM را نصب کنید.

 npm install --save-dev husky

موارد زیر را در ترمینال در ریشه برنامه اجرا کنید تا Husky را طوری پیکربندی کنید که هر زمان که git commit اجرا می‌شود lint-staged اجرا شود (در قلاب pre-commit Git):

 npx husky init echo "npx lint-staged" > .husky/pre-commit

اکنون باید یک فایل .husy/pre-commit در پوشه برنامه خود داشته باشید که فقط یک خط دارد: npx lint-staged .

راه‌اندازی برنامه‌های گفت نی کد در مقابل

اگر از VS Code به‌عنوان ویرایشگر کد خود استفاده می‌کنید، می‌توانید پسوندهای VS Code زیر را برای ارائه پرده‌بندی و قالب‌بندی در ذخیره‌سازی فایل و برجسته‌سازی نحوی روی خطاهای پرده‌بندی نصب کنید:

پسوند ESLint

پسوند زیباتر

پسوند Stylint (اگر از SCSS استفاده می کنید و از Tailwind استفاده نمی کنید)

پسوند TaliwindCSS (اگر از Tailwind استفاده می کنید و نه SCSS)

موارد زیر را در یک فایل settings.json در پوشه .vscode پروژه قرار دهید (البته می توانید این تنظیمات را در فایل تنظیمات کاربر خود نیز قرار دهید. می توانید از Command Palette Ctrl + P به آن دسترسی داشته باشید).

 { "[javascript]" : { "editor.defaultFormatter" : "esbenp.prettier-vscode" }, "[typescript]" : { "editor.defaultFormatter" : "esbenp.prettier-vscode" }, "[typescriptreact]" : { "editor.defaultFormatter" : "esbenp.prettier-vscode" }, "[javascriptreact]" : { "editor.defaultFormatter" : "esbenp.prettier-vscode" }, "[scss]" : { "editor.defaultFormatter" : "esbenp.prettier-vscode" }, "stylelint.validate" : [ "css" , "scss" ], "editor.formatOnSave" : true }

پس از راه‌اندازی، برنامه‌های گفت نی پرز می‌شوند و در Save فرمت می‌شوند.

تحلیل نهایی و عیب یابی

اکنون زمان ساخت و تعهد است:

 npm run format npm run build git add . git commit -m "fix: set up linting and formatting"

ساختن و ارتکاب یک تحلیل سالم خوب برای تنظیمی است که ما به تازگی انجام دادیم.

اگر هر چیزی به درستی تنظیم نشده بود، ممکن است در حین ساخت یا در هنگام انجام خطاها دریافت کنید.

اگر قبلاً کدی در پروژه داشتید، ممکن است هنگام انجام پروژه چند خطا وجود داشته باشد. به طور معمول، این موارد را می توان با موارد زیر حل کرد:

گفت ن پوشه ها یا فایل ها به یکی از فایل های *ignore . به عنوان مثال، من قبلاً با نصب Storybook مقداری کد در پروژه خود داشتم. پس مجبور شدم پوشه ها را اضافه کنم .storybook و storybook-static به هر یک از .stylelintignore ، .eslintignore و .prettierignore همانطور که هر سه ابزار از آنها شکایت کردند.

 stories storybook-static

گفت ن افزونه ها برای انواع فایل خاص. به عنوان مثال ، من برای توصیف تست های ادغام ، پرونده های Gherkin .feature را در پروژه خود داشتم. Prettier نمی تواند این موارد را قالب بندی کند. پس من به سادگی دویدن ، زیباتر پلوژین-گرکین را اضافه کردم:

 npm install prettier-plugin-gherkin --save-dev

توجه داشته باشید که معمولاً نصب بسته برای یک افزونه زیباتر برای Prettier برای یافتن آن کافی است و پیکربندی اضافی لازم نیست.

به همین ترتیب ، Eslint هنگام مواجهه با پرونده های .cy.ts حاوی آزمایش های تعامل سرو برای برنامه من شکایت کرد. برای حل این خطای خط ، بسته NPM را برای افزونه Cypress Eslint نصب کردم و آن را مطابق توضیحات در اینجا تنظیم کردم (بر خلاف Prettier ، برای به دست آوردن این بسته ESLINT ، برخی از پیکربندی ها لازم بود).

پیکربندی Typescript ممکن است خیلی سخت باشد و ممکن است هنگام ساخت خطاهای زیادی وجود داشته باشد ، مانند:

که در هنگام استفاده از پیکربندی ESLINT برای TypeScript اتفاق می افتد که بسیار سختگیرانه است. " width="725" height="478" loading="lazy">

اگر نمی خواهید خطاهای فردی را در پایه کد موجود خود برطرف کنید ، و آنها برای غیرفعال کردن قوانین خاص در مکان های خطا با استفاده از نظرات ESLINT بسیار زیاد هستند (به تصویر زیر مراجعه کنید) ، ساده ترین راه حل غیرفعال کردن @typescript-eslint/recommended-type-checked پیکربندی @typescript-eslint/recommended-type-checked با اظهار نظر در .eslintrc.js و Uncormenting @typescript-eslint/recommended که کمتر سختگیرانه است.

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

که خطای ESLINT را در یک کد در یک پرونده نشان می دهد." width="865" height="217" loading="lazy">

پس من Ctrl + . برای نشان دادن اقدامات کد (در عوض می توانستم روی نماد زرد Lighbulb که در کنار شماره نشان داده شده است کلیک کنم) ، سپس "Disable @typescript/no-non-null-assertion برای کل پرونده" انتخاب کردم.

را نشان می دهد. یکی از این موارد اجازه می دهد Uoto یک قانون ESLINT را که باعث خطایی در خط کد انتخاب شده در حال حاضر می شود ، غیرفعال کند." width="878" height="326" loading="lazy">

این اظهار نظر /* eslint-disable @typescript-eslint/no-non-null-assertion */ در بالای پرونده من را برای غیرفعال کردن تمام موارد خطای خاص در پرونده قرار داده است:

که یک قانون خاص ESLINT را از طریق پرونده غیرفعال می کند." width="625" height="133" loading="lazy">

نتیجه گیری

این آموزش به شما نشان می دهد که چگونه می توانید ابزارهای لینتینگ و قالب بندی را در برنامه Next.js خود پیکربندی کنید. من امیدوارم که این هم برای درک تنظیمات داده شده ، پیش زمینه لازم را به شما داده و در صورت لزوم آنها را سفارشی کند.

خبرکاو