ஒவ்வொரு டெவலப்மென்ட் டீமிற்கும் இது போன்ற ஒரு கதை இருக்கும். ஒரு pull request அரை நாள் வரை திறந்தே இருக்கும். தர்க்கம் (logic) தவறாக இருப்பதாலோ அல்லது API ஒப்பந்தம் (contract) மாறியதாலோ அல்ல, மாறாக object literals-ல் trailing commas தேவையா என்பதில் இரண்டு reviewers மத்தியில் கருத்து வேறுபாடு ஏற்படுவதால். அந்த விவாதம் நீண்டு கொண்டே போகும். யாரோ ஒருவர் ஒரு style guide லிங்கைப் போடுவார்கள். மற்றொருவர் வேறு ஒரு வழிகாட்டியைக் கொண்டு வருவார். குறியீடு (code) இணைக்கப்படும் (merge) போது, உண்மையில் அவர்கள் எந்த அம்சங்களை (features) உருவாக்கிக் கொண்டிருந்தார்கள் என்பதற்கான சூழல் (context) அனைவருக்குமே விடுபட்டுப் போய்விடும்.

இந்தத் தர்க்கங்கள் விலை உயர்ந்தவை. இவை மூத்த பொறியாளர்களின் (senior engineer) நேரத்தை வீணடிக்கின்றன, குழுவினரிடையே ஒருவித அதிருப்தியை உருவாக்குகின்றன, மேலும் ஜூனியர் டெவலப்பர்களுக்கு மென்பொருள் பொறியியல் என்பது பெரும்பாலும் செமிகோலன்களை (semicolons) வைத்து விவாதிப்பதிலேயே இருக்கிறது என்ற தவறான எண்ணத்தை விதைக்கின்றன. மிக மோசமான விஷயம் என்னவென்றால்? தயாரிப்புக்கு (product) இதில் அக்கறையில்லை. உங்கள் பயனர்கள் ஒரு space-க்கும் tab-க்கும் உள்ள வித்தியாசத்தை ஒருபோதும் கவனிக்க மாட்டார்கள். ஆனால் நீங்கள் மேற்கோள் குறிகளை (quote marks) விவாதிப்பதில் மும்முரமாக இருந்ததால் சரி செய்யாத பிழையை (bug) அவர்கள் நிச்சயம் கவனிப்பார்கள்.

ஒருமைப்பாடு (Consistency) முக்கியமானதுதான். ஒரே நபர் எழுதியது போன்ற ஒரு codebase-ஐப் படிப்பது, ஆய்வு செய்வது (review) மற்றும் பிழைகளைக் கண்டறிவது (debug) எளிது. ஆனால் அந்த ஒருமைப்பாட்டை மனித முயற்சியால் (by hand) கட்டாயப்படுத்த முயல்வதே தவறு.

சலிப்பூட்டும் வேலைகளைத் தானியக்கமாக்குங்கள்

இதற்கான தீர்வு எளிமையானது. பார்மேட்டிங்கில் (formatting) இருந்து மனிதத் தலையீட்டை முழுமையாக நீக்கிவிடுங்கள். ஈகோ இல்லாத, சோர்வடையாத கருவிகளிடம் (tools) அதை ஒப்படைத்துவிடுங்கள்.

மூன்று கருவிகள் இதைச் சிறப்பாகக் கையாளுகின்றன.

Prettier உங்கள் குறியீட்டை எடுத்து தானாகவே மறுவடிவமைக்கிறது (reformats). இது அனுமதி கேட்காது. வரி நீளம் (line lengths), மேற்கோள் பாணிகள் (quote styles), அல்லது ஒரு நீண்ட function signature-ஐப் பல வரிகளாகப் பிரிப்பது எப்படி என்பது பற்றி நீங்கள் யோசிப்பதைத் தவிர்க்கலாம். நீங்கள் கோப்பைச் சேமித்தால் போதும், Prettier அதை ஒருமைப்படுத்துகிறது.

ESLint Prettier தொடாத சிக்கல்களைக் கையாள்கிறது. இது பயன்படுத்தப்படாத மாறிகள் (unused variables), சென்றடைய முடியாத குறியீடு (unreachable code), React hooks-ல் விடுபட்ட சார்புகள் (missing dependencies) மற்றும் வரலாற்று ரீதியாக பிழைகளுக்கு வழிவகுக்கும் முறைகளைக் கண்டறிகிறது. சரியாகத் தொகுக்கப்பட்டால் (configured), இது பார்மேட்டிங்கில் தலையிடாமல் குறியீட்டின் தரத்தில் (code quality) கவனம் செலுத்தும்.

Husky ஒரு pre-commit hook-ஐ நிறுவுகிறது. தானியங்கிச் சோதனைகள் (automated checks) வெற்றி பெறும் வரை உங்கள் களஞ்சியத்திற்குள் (repository) எதையும் நுழைய விடாமல் இது தடுக்கும். இது உங்கள் Git pipeline-ஐ ஒரு ஆலோசனைக் பெட்டியாக (suggestions box) இல்லாமல், ஒரு காவலராக (gatekeeper) மாற்றுகிறது.

இவை அனைத்தும் இணைந்து ஒரு வலுவான சுழற்சியை (tight loop) உருவாக்குகின்றன. நீங்கள் உள்ளூர் அளவில் (locally) உங்களுக்குத் தோன்றியபடி குறியீட்டை எழுதலாம். நீங்கள் commit செய்யும்போது, கருவிகள் அதைச் சுத்தம் செய்து சரிபார்க்கும். அதன் பின்னரே குறியீடு உங்கள் இயந்திரத்திலிருந்து வெளியேறும்.

இந்த குறிப்பிட்ட ஸ்டேக் (stack) ஏன் வேலை செய்கிறது

ESLint விதிகளைத் தனித்தனியாகச் சரிசெய்ய நீங்கள் வாரக்கணக்கில் செலவிடலாம். அந்தத் தூண்டுதலைத் தவிர்க்கவும். இங்கே நோக்கம் பாணியைப் (style) பற்றி விவாதிப்பதை நிறுத்துவதே தவிர, ஒரு புதிய ஸ்டைல் கைடு கியூரேட்டராக (style guide curator) முழுநேர வேலையை உருவாக்குவதல்ல.

Prettier வேண்டுமென்றே ஒரு குறிப்பிட்ட கருத்தைப் (opinionated) பின்பற்றுமாறு வடிவமைக்கப்பட்டுள்ளது. இது குறைந்த அளவிலான கட்டமைப்பு விருப்பங்களை (configuration options) மட்டுமே வழங்குகிறது, ஏனெனில் ஒவ்வொரு விருப்பமும் எதிர்காலத்தில் ஒரு விவாதமாக மாறும். இதன் இயல்பு அமைப்புகள் (defaults) சரியானவை. சில மாற்றங்களை மட்டும் தேர்ந்தெடுத்து, அவற்றை ஒருமுறை எழுதி வைத்துவிட்டு முன்னேறிச் செல்லுங்கள்.

ESLint-ஐ அதன் போக்கில் விட்டால், அது குறியீட்டுத் தரம் மற்றும் செமிகோலன் பயன்பாடு, indent அளவு போன்ற பார்மேட்டிங் விதிகள் இரண்டையும் கட்டாயப்படுத்த முயற்சிக்கும். இது Prettier உடன் மோதலை உருவாக்கும், ஏனெனில் இரண்டு கருவிகளும் ஒரே எழுத்துக்களைத் திருத்த முயற்சிக்கும். eslint-config-prettier என்ற தொகுப்பு (package), Prettier உடன் முரண்படும் அனைத்து ESLint விதிகளையும் முடக்குவதன் மூலம் இதைத் தீர்க்கிறது. இந்தத் பணிகளைப் பிரிப்பது மிகவும் முக்கியமானது. பார்மேட்டிங் (cosmetics) Prettier-ன் பொறுப்பு. தர்க்கம் (logic) ESLint-ன் பொறுப்பு.

தொடர்ச்சியான ஒருங்கிணைப்பில் (continuous integration - CI) மட்டும் சோதனைகளை இயக்குவது மிகவும் தாமதமானது. CI தோல்வியடையும் போது, நீங்கள் ஏற்கனவே குழப்பமான குறியீட்டை commit செய்துவிட்டீர்கள், மற்றொரு பணிக்கு மாறிவிட்டீர்கள், மற்றும் ஒரு pull request-ஐயும் தொடங்கியிருக்கலாம். அதைச் சரிசெய்ய மற்றொரு commit, மற்றொரு push மற்றும் மீண்டும் காத்திருப்புச் சுழற்சி தேவைப்படும். Husky அந்தப் பின்னூட்டச் சுழற்சியை (feedback loop) சில நொடிகளாகக் குறைக்கிறது. lint-staged ஒவ்வொரு முறையும் முழு களஞ்சியத்தையும் ஸ்கேன் செய்வதற்குப் பதிலாக, நீங்கள் உண்மையில் மாற்றிய கோப்புகளுக்கு மட்டும் கருவிகளை இயக்குவதன் மூலம் அதை வேகமாக்குகிறது.

படிப் படியாக அமைப்பது எப்படி

பின்வரும் அமைப்பு ஒரு நவீன JavaScript அல்லது React திட்டத்திற்காக வடிவமைக்கப்பட்டுள்ளது, ஆனால் சிறிய மாற்றங்களுடன் இது TypeScript, Vue அல்லது Node ஆகியவற்றிற்கும் பொருந்தும். உங்கள் திட்டத்தின் ரூட் (root) கோப்புறையிலிருந்து ஒவ்வொரு படிநிலையையும் இயக்கவும்.

அனைத்தையும் dev dependencies ஆக நிறுவுவதன் மூலம் தொடங்கவும்:

npm install -D prettier eslint husky lint-staged eslint-config-prettier