ప్రతి డెవలప్‌మెంట్ టీమ్‌కు ఇలాంటి కథ ఉంటుంది. ఒక pull request సగం రోజు పాటు అలాగే ఉంటుంది. లాజిక్ తప్పుగా ఉన్నందు వల్లనో లేదా API కాంట్రాక్ట్ మారినందు వల్లనో కాదు, కానీ ఆబ్జెక్ట్ లిటరల్స్‌కు (object literals) ట్రైలింగ్ కామాలు (trailing commas) అవసరమా లేదా అనే విషయంలో ఇద్దరు రివ్యూయర్‌ల మధ్య విభేదాలు రావడం వల్ల. ఆ చర్చ పెరుగుతూ పోతుంది. ఎవరో ఒకరు స్టైల్ గైడ్ లింక్ పోస్ట్ చేస్తారు. మరొకరు వేరే గైడ్‌తో దానికి ఎదురుదాడి చేస్తారు. కోడ్ మెర్జ్ అయ్యే సమయానికి, అసలు వారు ఏ ఫీచర్లను నిర్మిస్తున్నారో అనే విషయంపై పాల్గొన్న వారందరికీ అవగాహన (context) కోల్పోతుంది.

ఈ పోరాటాలు ఖరీదైనవి. ఇవి సీనియర్ ఇంజనీర్ల సమయాన్ని వృథా చేస్తాయి, తోటి సభ్యుల మధ్య అసహనాన్ని పెంచుతాయి మరియు సాఫ్ట్‌వేర్ ఇంజనీరింగ్ అంటే ఎక్కువగా సెమీకోలన్‌ల (semicolons) గురించి వాదించడం అని జూనియర్ డెవలపర్లు నమ్మేలా చేస్తాయి. అన్నిటికంటే దారుణమైన విషయం ఏమిటంటే? ప్రొడక్ట్‌కు దీనితో సంబంధం లేదు. స్పేస్ (space) వాడాలా లేక ట్యాబ్ (tab) వాడాలా అనే తేడాను మీ యూజర్లు ఎప్పుడూ గమనించరు. కానీ మీరు కోట్ మార్కుల (quote marks) గురించి చర్చించడంలో బిజీగా ఉండటం వల్ల సరిచేయని బగ్ (bug) ను వారు ఖచ్చితంగా గమనిస్తారు.

కన్సిస్టెన్సీ (Consistency) ముఖ్యం. ఒకే వ్యక్తి రాసినట్లుగా ఉండే కోడ్‌బేస్ చదవడానికి, రివ్యూ చేయడానికి మరియు డీబగ్ (debug) చేయడానికి సులభంగా ఉంటుంది. అయితే ఆ కన్సిస్టెన్సీని మాన్యువల్‌గా అమలు చేయడానికి ప్రయత్నించడమే తప్పు.

బోరింగ్ పనులను ఆటోమేట్ చేయండి

దీనికి పరిష్కారం చాలా సరళమైనది. ఫార్మాటింగ్ విషయంలో మానవ నిర్ణయాలను పూర్తిగా తొలగించండి. అహం (ego) లేని మరియు అలసిపోని టూల్స్‌కు ఆ బాధ్యతను అప్పగించండి.

మూడు టూల్స్ దీనిని చక్కగా నిర్వహిస్తాయి.

Prettier మీ కోడ్‌ను తీసుకుని దానిని ఆటోమేటిక్‌గా రీఫార్మాట్ చేస్తుంది. ఇది ఎవరి అనుమతిని అడగదు. లైన్ పొడవు (line lengths), కోట్ స్టైల్స్ (quote styles), లేదా ఒక పొడవైన ఫంక్షన్ సిగ్నేచర్‌ను లైన్ల మధ్య ఎలా విభజించాలనే దాని గురించి మీరు ఆలోచించాల్సిన అవసరం ఉండదు. మీరు ఫైల్‌ను సేవ్ చేస్తే చాలు, Prettier దానిని కన్సిస్టెంట్‌గా మారుస్తుంది.

ESLint Prettier తాకని సమస్యలను పరిష్కరిస్తుంది. ఇది ఉపయోగించని వేరియబుల్స్ (unused variables), చేరుకోలేని కోడ్ (unreachable code), React హుక్స్‌లో మిస్సింగ్ డిపెండెన్సీలు (missing dependencies) మరియు గతంలో బగ్స్‌కు దారితీసిన ప్యాటర్న్‌లను గుర్తిస్తుంది. సరిగ్గా కాన్ఫిగర్ చేసినప్పుడు, ఇది ఫార్మాటింగ్‌కు దూరంగా ఉండి, అసలు కోడ్ క్వాలిటీపై దృష్టి పెడుతుంది.

Husky ఒక pre-commit hookను ఇన్‌స్టాల్ చేస్తుంది, ఇది ఆటోమేటెడ్ చెక్‌లు పాస్ అయ్యే వరకు మీ రిపోజిటరీలోకి ఏదీ రాకుండా అడ్డుకుంటుంది. ఇది మీ Git పైప్‌లైన్‌ను కేవలం సలహాలు ఇచ్చే బాక్స్‌లా కాకుండా, ఒక గేట్‌కీపర్‌లా మారుస్తుంది.

ఇవన్నీ కలిసి ఒక పటిష్టమైన లూప్‌ను (tight loop) ఏర్పరుస్తాయి. మీరు లోకల్‌గా మీకు నచ్చినట్లుగా కోడ్ రాయవచ్చు. మీరు కమిట్ చేసినప్పుడు, ఈ టూల్స్ దానిని క్లీన్ చేసి చెక్ చేస్తాయి. అప్పుడే ఆ కోడ్ మీ మెషీన్ నుండి బయటకు వెళ్తుంది.

ఈ నిర్దిష్ట స్టాక్ ఎందుకు పనిచేస్తుంది

ESLint రూల్స్‌ను మాన్యువల్‌గా ట్యూన్ చేయడానికి మీరు వారాల సమయం వెచ్చించవచ్చు. కానీ ఆ కోరికను అదుపులో ఉంచుకోండి. ఇక్కడ లక్ష్యం స్టైల్ గురించి చర్చించడం ఆపడం మాత్రమే, స్టైల్ గైడ్ క్యూరేటర్‌గా కొత్త ఫుల్-టైమ్ ఉద్యోగాన్ని సృష్టించడం కాదు.

Prettier కావాలనే 'opinionated'గా రూపొందించబడింది. ఇది పరిమితమైన కాన్ఫిగరేషన్ ఆప్షన్లను మాత్రమే అందిస్తుంది, ఎందుకంటే ప్రతి ఆప్షన్ భవిష్యత్తులో ఒక చర్చకు దారితీస్తుంది. దీని డిఫాల్ట్ సెట్టింగ్స్ చాలా బాగుంటాయి. కొన్ని చిన్న మార్పులను (overrides) ఎంచుకుని, వాటిని ఒకసారి రాసి వదిలేయండి.

ESLintను దాని స్వంత నిర్ణయాలకు వదిలేస్తే, అది కోడ్ క్వాలిటీ మరియు ఫార్మాటింగ్ రూల్స్ (సెమీకోలన్ వాడకం మరియు ఇండెంట్ సైజు వంటివి) రెండింటినీ అమలు చేయడానికి ప్రయత్నిస్తుంది. ఇది Prettierతో ఘర్షణకు దారితీస్తుంది, ఎందుకంటే రెండు టూల్స్ ఒకే క్యారెక్టర్లను ఎడిట్ చేయడానికి ప్రయత్నిస్తాయి. eslint-config-prettier ప్యాకేజీ, Prettierతో విభేదించే అన్ని ESLint రూల్స్‌ను డిసేబుల్ చేయడం ద్వారా ఈ సమస్యను పరిష్కరిస్తుంది. ఈ బాధ్యతల విభజన చాలా కీలకం. ఫార్మాటింగ్ (cosmetics) బాధ్యత Prettierది, లాజిక్ బాధ్యత ESLintది.

కేవలం కంటిన్యూయస్ ఇంటిగ్రేషన్ (CI)లో మాత్రమే చెక్‌లు రన్ చేయడం అనేది చాలా ఆలస్యం అవుతుంది. CI ఫెయిల్ అయ్యే సమయానికి, మీరు ఇప్పటికే గజిబిజి కోడ్‌ను కమిట్ చేసి, వేరే పనికి మారిపోయి ఉండవచ్చు లేదా బహుశా ఒక pull request కూడా ఓపెన్ చేసి ఉండవచ్చు. దానిని సరిచేయడానికి మరొక కమిట్, మరొక పుష్ మరియు మరొక వెయిటింగ్ సైకిల్ అవసరమవుతుంది. Husky ఆ ఫీడ్‌బ్యాక్ లూప్‌ను సెకన్లకు తగ్గిస్తుంది. Lint-staged ప్రతి కమిట్‌కు మొత్తం రిపోజిటరీని స్కాన్ చేయకుండా, మీరు నిజంగా మార్చిన ఫైల్‌లపై మాత్రమే టూల్స్‌ను రన్ చేయడం ద్వారా ప్రక్రియను వేగవంతం చేస్తుంది.

స్టెప్ బై స్టెప్ సెటప్ చేయడం

ఈ క్రింది సెటప్ ఆధునిక JavaScript లేదా React ప్రాజెక్ట్‌ల కోసం రూపొందించబడింది, కానీ చిన్న మార్పులతో దీనిని TypeScript, Vue లేదా Node ప్రాజెక్ట్‌లకు కూడా ఉపయోగించవచ్చు. ప్రతి స్టెప్‌ను మీ ప్రాజెక్ట్ రూట్ (project root) నుండి రన్ చేయండి.

అన్నింటినీ dev dependenciesగా ఇన్‌స్టాల్ చేయడం ద్వారా ప్రారంభించండి:

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