Migrera ett firebase-projekt från TSLint till ESLint

Efter att Palantir, som är huvudansvarig för TSLint, avskaffade det under 2019, gick många team - inklusive vårt - över till det faktiska verktyget för att kontrollera Typescript: ESLint. Det här inlägget kommer att täcka hur vi migrerade vår typescript-kodbas med hjälp av ett snyggt konverteringsverktyg, prata om några manuella korrigeringar som vi var tvungna att göra och sammanfatta våra viktigaste lärdomar.

Låt oss fastställa bakgrunden till projektet innan vi börjar. Vårt team ansvarar för backend av Unloc s plattform, som består av vårt API, datahantering, periodiska jobb osv. Vi underhåller och utvecklar en omfattande Firebase-backend som består av över 80 000 rader kod skrivna i Typescript.

Som ett växande team med ingenjörer med olika bakgrund ser vi värdet av att sträva efter en gemensam kodstil för vår kodbas. Vi var lyckliga campare som använde TSLint, men sedan dess avveckling var vi tvungna att leta efter ett skydd; ett annat verktyg som skyddar oss från oss själva. Vi bestämde oss slutligen för att följa Palantirs rekommendation och övergå till ESLint.

Varför använda en linter överhuvudtaget?

Låt oss först definiera vad en linter är. En linter är ett verktyg som används för att analysera kod, för att upptäcka programmeringsfel, buggar, stilistiska fel och misstänkta konstruktioner. Användningen medför många fördelar för alla programvaruprojekt. Istället för att lägga tid och kraft på att kommentera stilproblem i en pull request kan du fokusera på det viktiga: gör den här koden det den ska på ett rent och effektivt sätt?

Linters och automatiska formatörer används i stor utsträckning av branschledande företag som Google, och vissa programmeringsspråk som Go och Elm har dem till och med inbyggda som en del av språket.

Som utvecklare vet vi att en kort cykeltid är viktig för produktiviteten. Därför bör fel i linting, formatering och testfel upptäckas så tidigt som möjligt i utvecklingsfasen.

När du arbetar med linters är det bästa sättet att integrera dem i din favorit IDE. De flesta av dem har ett brett utbud av tillägg för detta, så att du blir varnad när du introducerar ett fel. Slutligen, som en sista kontroll: Om du använder ett byggsystem, se till att lägga till ett lintingsteg som säkerställer att endast felfri kod läggs in i din huvudgren.

Migrera med verktyget tslint-to-eslint-config

När vi slutligen bestämde oss för att göra migreringen fick vi lyckligtvis reda på att det finns ett fantastiskt verktyg med öppen källkod som heter tslint-to-eslint-config. Med ett enda kommando konverterar det här verktyget din TSLint-konfiguration till närmaste möjliga ESLint-ekvivalent. Det bästa är att du kan köra det med npx - så du behöver inte installera några paket. ⚡️Låt oss prova det!

‍

När tslint-to-eslint-config har avslutat sin körning genererar den en ny .eslintrc.js-fil med motsvarande ESLint-regler baserat på projektets nuvarande TSLint-regler. Verktyget migrerar de flesta TSLint-regler, men du bör vara uppmärksam på dess utdata i terminalen; vissa regler kan behöva konverteras manuellt.

Detta kan också vara ett utmärkt tillfälle att se över projektets regelverk. Vissa regler kanske inte längre är relevanta? Både ESLint och typescript-eslint har en uppsättning rekommenderade regler om du behöver några standardregler.

Installera nödvändiga beroenden

Ytterligare beroenden för olika linting-paket kan behövas för att slutföra migreringen. De exakta paketen kommer att variera beroende på ditt projekts specifika regelverk. Se konsolutgången du fick och lägg till dem i din package.json.

Koppla ESLint till utvecklingsflödet

Här på Unloc kör vi vår lintingprocess med hjälp av npm-skript, så vi var tvungna att uppdatera vårt lint-skript i package.json för att köra ESLint istället för TSLint:

Detta länkar filer med tillägget .ts och .tsx som finns i katalogerna src/ och test/.

Ett konstigt fel 🐛

Eftersom allt inte kan vara perfekt i livet - fick vi ett konstigt fel efter konverteringen:

Det visade sig att på grund av ett prestandaproblem i ESLint måste alla lintade filer refereras från tsconfig.json. Och det var .eslintrc.js som orsakade problemet! Vi löste detta genom att lägga till en referens till den i tsconfig.jsons"include"-array:

Att städa upp

Vi är nästan framme! Nu behöver vi bara ta bort den gamla tslint.json och skapa en Pull Request, så är vi klara!

Slutsats

Migreringen från TSLint till ESLint var något vi sköt upp till framtiden, eftersom vi var rädda för att det skulle bli en långdragen process med många buggar. Tack vare tslint-to-eslint-config var migreringen en barnlek och vi behövde bara göra en snabb felrättning för ett projekt med över 80 000 rader TypeScript-kod.

Om du bestämmer dig för att migrera till ESLint - vilket du definitivt bör göra - bör du tänka på de här stegen:

1. Kör tslint-to-eslint-config i projektkatalogen.
2. Inspektera de nyligen skapade reglerna och anpassa dem så att de uppfyller kraven i ditt projekt.
3. Installera eventuella ytterligare beroenden som krävs för din specifika lintingprocess.
4. Koppla ESLint till dina utvecklingsverktyg, CI- och/eller byggverktyg.
5. Ta bort de numera oanvända TSLint-filerna och tryck dina ändringar!

Lärandepunkter 👩🏫

Att se över vår linting-installation påminde oss om vikten av linting och formatering - och deras roll i en sund utvecklingsprocess.

Kom ihåg att linters inte är avsedda att kontrollera formateringen av din kod, du bör använda specialiserade verktyg för båda: ESLint för linting och Prettier till exempel för formatering.

Med tiden har vi lärt oss att lintingfel har en tendens att smyga sig tillbaka in i kodbasen. För att upprätthålla våra lintingregler bör vi lägga till ett steg för dem i vår CI-process.

Slutligen har vi många anpassade regler som kan vara svåra att underhålla, så det vore bra att hålla sig till den rekommenderade regeluppsättningen från ESLint.

Lycka till med kodningen!