Vitet e fundit kam arritur të vlerësoj shumë ESLint. Një litar i fuqishëm dhe i besueshëm JavaScript, ESLint mund të përdoret jo vetëm për të zbuluar gabimet e zakonshme të programimit, por edhe për të zbatuar një stil të qëndrueshëm kodi. Dobia e tij nuk mund të mbivlerësohet. Shokët tuaj të skuadrës dhe vetja juaj e ardhshme do t'ju falënderojnë për përdorimin e tij.
Unë rekomandoj që ESLint të aktivizohet përpara se të shkruhet ndonjë kod, por çfarë ndodh me projektet ekzistuese? Një zhvillues që drejton ESLint në një bazë kodesh ekzistuese sigurisht që do të jetë i mbingarkuar; do të paralajmërojë për një sërë çështjesh që nuk ishin vënë re deri në atë moment. A ka ndonjë mënyrë për të miratuar gradualisht rekomandimet e tij? Më e rëndësishmja, a ka ndonjë mënyrë për të parandaluar rritjen e numrit të problemeve? Përdorimi i linterit në CI nuk është zgjidhje. Thjesht do të dështojë dhe do të mërzitë të tjerët.
E mora parasysh këtë dilemë kur fillova të punoja në GLAM, një panel metrikë të produkteve të vetë-shërbimit nga i mrekullueshëmi Hamilton Ulmer. GLAM aktualisht nuk është e lehtë për t'u instaluar për përdorim të jashtëm, por po fiton popullaritet brenda Mozilla-s.
Për një kohë, unë do të drejtoja manualisht ESLint kundër kërkesave për tërheqje dhe do t'i njoftoja shokët e mi të skuadrës kur paraqitnin probleme të reja. Do të dokumentoja saktësisht se cilat probleme u shtuan dhe saktësisht në cilat rreshta u shfaqën. Kjo funksionoi, por ishte një proces manual dhe i ngadaltë. Shokët e mi të skuadrës mund të mos dinë për problemet e reja të ESLint derisa të filloja të rishikoja kodin.
Për të adresuar dobësitë e kësaj zgjidhjeje manuale, kam shkruar një skript të vogël Node i cili paralajmëron nëse numri i problemeve të ESLint tejkalon një kufi të konfiguruar. Nëse numri i problemeve është më i ulët, skripti inkurajon zhvilluesin që të ul kufirin e konfiguruar për të parandaluar regresionet. E thjeshtë, por efektive.
Ekzekutoni skriptin me node eslint-health.Pasi ta bëni këtë, do të shihni:
Po vrapon…
Problemet maksimale të ESLint: 50
Numri i problemeve ESLint: 57
Dështo: Numri i problemeve ESLint › max
SHËNIM: Ndryshimet e fundit mund të kenë sjellë probleme të reja ESLint
or:
Po vrapon…
Problemet maksimale të ESLint: 50
Numri i problemeve ESLint: 48
PASS: Numri i problemeve ESLint ‹= max
SHËNIM: Duke marrë parasysh uljen e config.maxProblems në 48 në skriptin eslint-health për të parandaluar regresionet
E di se çfarë po mendoni: do të ishte edhe më mirë që zhvilluesit të theksonin problemet ESLint në redaktorët e tyre. Jam dakord, por kur ka një numër kaq të madh problemesh ESLint, zhvilluesit zakonisht mund të injorojnë problemet që shohin. Plus, asgjë më shumë se bllokimi i bashkimit me këtë lloj kontrolli, duke supozuar se skripti ekzekutohet automatikisht në CI.
Unë mendoj se kjo do të motivojë ekipin tonë që gradualisht të zvogëlojë numrin tonë të problemeve të ESLint në zero. Në atë pikë, skenari mund të largohet, pasi i ka shërbyer qëllimit të tij. Po funksionon deri më tani: ne e reduktuam kufirin tonë dy herë në vetëm 24 orët e fundit.
Nëse preferoni të përdorni një skript Bash, unë në fakt "shkrova një" përpara se të rishkruaj logjikën në Node. Ka më shumë gjasa të prishet sepse nuk ka qasje të drejtpërdrejtë në ESLint API, por unë e shoh se është më i lexueshëm.
Ju lutemi mos ngurroni të përdorni cilindo nga këto skripta kudo që mendoni se do të ishin të dobishëm; të gjithë Gists e mia publike janë "të përbashkëta sipas kushteve të licencës MIT".
