എല്ലാ ഡെവലപ്മെന്റ് ടീമുകൾക്കും ഇത്തരത്തിലുള്ള കഥകളുണ്ടാകും. ഒരു pull request പകുതി ദിവസമോ അതിൽ കൂടുതലോ തുറന്നു കിടക്കുന്നു. ലോജിക് തെറ്റായതുകൊണ്ടോ API കോൺട്രാക്ട് മാറിയതുകൊണ്ടോ അല്ല, മറിച്ച് ഒബ്ജക്റ്റ് ലിറ്ററലുകളിൽ (object literals) ട്രെയ്ലിംഗ് കോമകൾ (trailing commas) വേണോ വേണ്ടയോ എന്ന കാര്യത്തിൽ രണ്ട് റിവ്യൂവർമാർ തമ്മിലുള്ള അഭിപ്രായവ്യത്യാസം കാരണമാണ് ഇത്. ചർച്ചകൾ നീളുന്നു. ഒരാൾ സ്റ്റൈൽ ഗൈഡ് ലിങ്ക് പങ്കുവെക്കുന്നു. മറ്റൊരാൾ മറ്റൊരു ഗൈഡ് നിരത്തുന്നു. കോഡ് മെർജ് ചെയ്യുന്ന സമയമാകുമ്പോഴേക്കും, യഥാർത്ഥത്തിൽ നിർമ്മിച്ചുകൊണ്ടിരുന്ന ഫീച്ചറുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ (context) എല്ലാവർക്കും നഷ്ടപ്പെട്ടിട്ടുണ്ടാകും.
ഇത്തരം തർക്കങ്ങൾ ചിലവേറിയതാണ്. അവ സീനിയർ എഞ്ചിനീയർമാരുടെ മണിക്കൂറുകൾ പാഴാക്കുന്നു, സഹപ്രവർത്തകർക്കിടയിൽ ചെറിയ രീതിയിലുള്ള അതൃപ്തി ഉണ്ടാക്കുന്നു, കൂടാതെ സോഫ്റ്റ്വെയർ എഞ്ചിനീയറിംഗ് എന്നത് പ്രധാനമായും സെമി കോളനുകളെ (semicolons) ചൊല്ലിയുള്ള തർക്കങ്ങൾ ജയിക്കുന്നതാണെന്ന് ജൂനിയർ ഡെവലപ്പർമാരെ തെറ്റിദ്ധരിപ്പിക്കുന്നു. ഏറ്റവും മോശമായ ഭാഗം എന്താണെന്നോ? പ്രൊഡക്റ്റിന് ഇതിലൊന്നും താൽപ്പര്യമില്ല. ഒരു സ്പേസ് വേണോ അതോ ടാബ് വേണോ എന്നതിനെക്കുറിച്ച് നിങ്ങളുടെ ഉപയോക്താക്കൾ ഒരിക്കലും ശ്രദ്ധിക്കില്ല. പകരം, കോട്ട് മാർക്കുകളെ (quote marks) ചൊല്ലിയുള്ള തർക്കങ്ങളിൽ നിങ്ങൾ മുഴുകിയിരുന്നതുകൊണ്ട് പരിഹരിക്കാൻ കഴിയാതെ പോയ ബഗ്ഗുകളെ അവർ ശ്രദ്ധിക്കും.
കൺസിസ്റ്റൻസി (Consistency) പ്രധാനമാണ്. ഒരാൾ മാത്രം എഴുതിയതുപോലെ തോന്നിക്കുന്ന ഒരു കോഡ്ബേസ് വായിക്കാനും റിവ്യൂ ചെയ്യാനും ഡീബഗ് ചെയ്യാനും എളുപ്പമാണ്. എന്നാൽ ആ കൺസിസ്റ്റൻസി കൈകൊണ്ട് (manually) നടപ്പിലാക്കാൻ ശ്രമിക്കുന്നതാണ് തെറ്റ്.
Automate the Boring Stuff
ഇതിനുള്ള പരിഹാരം ലളിതമാണ്. ഫോർമാറ്റിംഗിൽ നിന്നുള്ള മനുഷ്യന്റെ ഇടപെടൽ പൂർണ്ണമായും ഒഴിവാക്കുക. ഈ ജോലി അഹങ്കാരമില്ലാത്തതും തളരാത്തതുമായ ടൂളുകൾക്ക് കൈമാറുക.
മൂന്ന് ടൂളുകൾ ഇത് കൃത്യമായി ചെയ്യുന്നു.
Prettier നിങ്ങളുടെ കോഡ് എടുത്ത് സ്വയം ഫോർമാറ്റ് ചെയ്യുന്നു. അത് അനുവാദം ചോദിക്കാറില്ല. ലൈൻ ദൈർഘ്യം (line lengths), കോട്ട് സ്റ്റൈലുകൾ, അല്ലെങ്കിൽ ഒരു വലിയ ഫംഗ്ഷൻ സിഗ്നേച്ചർ എങ്ങനെ വരികളായി തിരിക്കണം എന്നതിനെക്കുറിച്ച് നിങ്ങൾ ചിന്തിക്കേണ്ടതില്ല. നിങ്ങൾ ഫയൽ സേവ് ചെയ്യുമ്പോൾ Prettier അത് കൺസിസ്റ്റന്റ് ആക്കുന്നു.
ESLint Prettier ശ്രദ്ധിക്കാത്ത പ്രശ്നങ്ങൾ കൈകാര്യം ചെയ്യുന്നു. ഉപയോഗിക്കാത്ത വേരിയബിളുകൾ (unused variables), റീച്ചബിൾ അല്ലാത്ത കോഡുകൾ (unreachable code), React ഹുക്കുകളിലെ മിസ്സിംഗ് ഡിപെൻഡൻസികൾ, ബഗുകൾക്ക് കാരണമാകുന്ന പാറ്റേണുകൾ എന്നിവ ഇത് കണ്ടെത്തുന്നു. ശരിയായി കോൺഫിഗർ ചെയ്താൽ, ഇത് ഫോർമാറ്റിംഗിൽ നിന്ന് മാറി യഥാർത്ഥ കോഡ് ക്വാളിറ്റിയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു.
Husky ഒരു pre-commit hook ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ഓട്ടോമേറ്റഡ് ചെക്കുകൾ പാസാകുന്നത് വരെ നിങ്ങളുടെ റെപ്പോസിറ്ററിയിലേക്ക് ഒന്നും പ്രവേശിക്കുന്നത് ഇത് തടയുന്നു. ഇത് നിങ്ങളുടെ Git പൈപ്പ്ലൈനെ വെറുമൊരു നിർദ്ദേശ പെട്ടിയല്ല (suggestions box), മറിച്ച് ഒരു കാവൽക്കാരനാക്കി (gatekeeper) മാറ്റുന്നു.
ഇവയെല്ലാം ചേർന്ന് ഒരു ടൈറ്റ് ലൂപ്പ് (tight loop) രൂപീകരിക്കുന്നു. ലോക്കലായി നിങ്ങൾക്ക് ഇഷ്ടമുള്ള രീതിയിൽ കോഡ് എഴുതാം. നിങ്ങൾ കമിറ്റ് ചെയ്യുമ്പോൾ, ടൂളുകൾ അത് വൃത്തിയാക്കുകയും പരിശോധിക്കുകയും ചെയ്യുന്നു. അതിനുശേഷം മാത്രമേ കോഡ് നിങ്ങളുടെ മെഷീനിൽ നിന്ന് പുറത്തേക്ക് പോകൂ.
Why This Specific Stack Works
ESLint റൂളുകൾ കൈകൊണ്ട് ട്യൂൺ ചെയ്യാൻ നിങ്ങൾക്ക് ആഴ്ചകൾ ചിലവഴിച്ചേക്കാം. ആ ആഗ്രഹം നിയന്ത്രിക്കുക. ഇവിടെ ലക്ഷ്യം സ്റ്റൈലിനെക്കുറിച്ച് തർക്കിക്കുന്നത് നിർത്തുക എന്നതാണ്, അല്ലാതെ ഒരു സ്റ്റൈൽ ഗൈഡ് ക്യൂറേറ്റർ എന്ന നിലയിൽ പുതിയൊരു ഫുൾ ടൈം ജോലി ഉണ്ടാക്കുകയല്ല.
Prettier മനഃപൂർവ്വം 'opinionated' ആണ്. ഇത് പരിമിതമായ കോൺഫിഗറേഷൻ ഓപ്ഷനുകൾ മാത്രമേ നൽകുന്നുള്ളൂ, കാരണം ഓരോ ഓപ്ഷനും ഭാവിയിൽ ഒരു തർക്കത്തിന് കാരണമായേക്കാം. ഇതിലെ ഡിഫോൾട്ട് സെറ്റിംഗുകൾ യുക്തിസഹമാണ്. കുറച്ച് ഓവർറൈഡുകൾ (overrides) മാത്രം തിരഞ്ഞെടുക്കുക, അവ ഒരിക്കൽ എഴുതി വെക്കുക, എന്നിട്ട് മുന്നോട്ട് പോവുക.
ESLint അതിന്റെ രീതിയിൽ പ്രവർത്തിച്ചാൽ, കോഡ് ക്വാളിറ്റിയും സെമി കോളൻ ഉപയോഗം, ഇൻഡന്റ് സൈസ് (indent size) തുടങ്ങിയ ഫോർമാറ്റിംഗ് റൂളുകളും ഒരുപോലെ നടപ്പിലാക്കാൻ ശ്രമിക്കും. ഇത് Prettier-മായി സംഘർഷമുണ്ടാക്കും, കാരണം രണ്ട് ടൂളുകളും ഒരേ ക്യാരക്ടറുകൾ എഡിറ്റ് ചെയ്യാൻ ശ്രമിക്കും. eslint-config-prettier എന്ന പാക്കേജ് Prettier-മായി ഏറ്റുമുട്ടുന്ന എല്ലാ ESLint റൂളുകളും ഡിസേബിൾ ചെയ്തുകൊണ്ട് ഈ പ്രശ്നം പരിഹരിക്കുന്നു. ഈ ചുമതലകളുടെ വിഭജനം (separation of duties) വളരെ പ്രധാനമാണ്. കോസ്മെറ്റിക്സ് (cosmetics) Prettier-ന്റെ ചുമതലയാണ്, ലോജിക് (logic) ESLint-ന്റേതുമാണ്.
കൺറ്റിന്യൂവസ് ഇന്റഗ്രേഷൻ (CI) സമയത്ത് മാത്രം ചെക്കുകൾ റൺ ചെയ്യുന്നത് വളരെ വൈകിപ്പോകും. CI പരാജയപ്പെടുമ്പോഴേക്കും നിങ്ങൾ അലങ്കോലമായ കോഡ് കമിറ്റ് ചെയ്യുകയും, മറ്റൊരു ടാസ്കിലേക്ക് മാറുകയും, ഒരുപക്ഷേ ഒരു pull request ഓപ്പൺ ചെയ്യുകയും ചെയ്തിട്ടുണ്ടാകും. അത് ശരിയാക്കാൻ മറ്റൊരു കമിറ്റും പുഷും (push) കാത്തിരിപ്പും ആവശ്യമാണ്. Husky ഈ ഫീഡ്ബാക്ക് ലൂപ്പ് സെക്കൻഡുകളിലേക്ക് ചുരുക്കുന്നു. ഓരോ കമിറ്റിലും മുഴുവൻ റെപ്പോസിറ്ററിയും സ്കാൻ ചെയ്യുന്നതിന് പകരം, നിങ്ങൾ മാറ്റം വരുത്തിയ ഫയലുകളിൽ മാത്രം ടൂളുകൾ പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ lint-staged ഇത് വേഗത്തിലാക്കുന്നു.
Setting It Up Step by Step
താഴെ പറയുന്ന സെറ്റപ്പ് ഒരു മോഡേൺ JavaScript അല്ലെങ്കിൽ React പ്രോജക്റ്റിന് വേണ്ടിയുള്ളതാണ്, എന്നാൽ ചെറിയ മാറ്റങ്ങളോടെ ഇത് TypeScript, Vue, അല്ലെങ്കിൽ Node എന്നിവയിലും ഉപയോഗിക്കാം. ഓരോ സ്റ്റെപ്പും നിങ്ങളുടെ പ്രോജക്റ്റ് റൂട്ടിൽ നിന്ന് റൺ ചെയ്യുക.
എല്ലാം dev dependencies ആയി ഇൻസ്റ്റാൾ ചെയ്തുകൊണ്ട് തുടങ്ങുക:
npm install -D prettier eslint husky lint-staged eslint-config-prettier