Migrering av et firebase-prosjekt fra TSLint til ESLint

Etter avviklingen av TSLint i 2019 av Palantir, dens primære vedlikeholder, flyttet mange team – inkludert vårt – til de facto lint-verktøyet for Typescript: ESLint . Dette innlegget vil dekke hvordan vi migrerte typescript-kodebasen vår ved hjelp av et pent konverteringsverktøy, snakke om noen manuelle fiksinger som vi måtte gjøre, og oppsummere hovedpoengene våre.

La oss etablere bakgrunnen for prosjektet før vi setter i gang. Vårt team er ansvarlig for backend av Unloc sin plattform, som består av vår API, datahåndtering, periodiske jobber etc. Vi vedlikeholder og utvikler en omfattende Firebase-backend bestående av over 80 000 linjer med kode skrevet i Typescript.

Som et voksende team med ingeniører som kommer fra forskjellige bakgrunner, ser vi verdien av å sikte på en felles kodestil for kodebasen vår. Vi var glade campere som brukte TSLint, men siden den ble avviklet, måtte vi lete etter ly; et annet verktøy for å beskytte oss mot oss selv. Vi bestemte oss til slutt for å følge Palantirs anbefaling og migrere til ESLint.

Hvorfor bruke en linter i utgangspunktet?

Først, la oss definere hva en linter er. En linter er et verktøy som brukes til å analysere kode, for å flagge programmeringsfeil, feil, stilistiske feil og mistenkelige konstruksjoner. Bruken gir mange fordeler til ethvert programvareprosjekt. I stedet for å bruke tid og krefter på å kommentere stilproblemer i en pull-forespørsel, kan du fokusere på de viktige tingene: gjør denne koden det den skal på en ren og effektiv måte?

Linters og autoformatere er mye brukt av bransjeledende selskaper som Google, og noen programmeringsspråk som Go og Elm har dem innebygd som en del av språket.

Som utviklere vet vi at kort syklustid er viktig for produktiviteten. Derfor bør fôrings-, formaterings- og testfeil oppdages så tidlig som mulig i utviklingsfasen.

Når du arbeider med linters, er den beste praksisen å integrere dem i din favoritt-IDE. De fleste av dem vil ha et bredt utvalg av utvidelser for dette, slik at du blir varslet når du introduserer en feil. Til slutt, som siste sjekk: hvis du bruker et byggesystem, sørg for å legge til et linting-trinn som sikrer at bare feilfri kode tas inn i hovedgrenen din.

Migrerer med tslint-to-eslint-config-verktøyet

Heldigvis for oss, da vi endelig bestemte oss for å gjøre migreringen fant vi ut at det er et flott åpen kildekodeverktøy kalt tslint-to-eslint-config . Med én enkelt kommando vil dette verktøyet konvertere TSLint-konfigurasjonen til nærmeste mulige ESLint-ekvivalent. Det beste er at du kan kjøre det ved å bruke npx - så det er ikke nødvendig å installere noen pakker. ⚡️La oss prøve det!

‍

Etter å ha fullført utførelsen, genererer tslint-to-eslint-config en ny .eslintrc.js -fil med de tilsvarende ESLint-reglene basert på prosjektets gjeldende TSLint-regler. Verktøyet vil migrere de fleste TSLint-regler, men du bør være oppmerksom på utdataene i terminalen; noen regler kan trenge manuell konvertering.

Dette kan også være en flott mulighet til å se på prosjektets regelsett på nytt. Noen regler er kanskje ikke relevante lenger? Både ESLint og typescript-eslint har et sett med anbefalte regler i tilfelle du trenger noen standardinnstillinger.

Installere nødvendige avhengigheter

Ytterligere avhengigheter for ulike linting-pakker kan være nødvendig for å fullføre migreringen. De nøyaktige pakkene vil variere avhengig av det spesifikke regelsettet for prosjektet ditt. Se konsollutgangen du fikk og legg dem til package.json .

Kobler ESLint til utviklingsflyten

Her kl Unloc vi kjører linting-prosessen vår ved å bruke npm-skript , så vi måtte oppdatere lint-skriptet vårt i vår package.json for å kjøre ESLint i stedet for TSLint:

Dette fletter filer med filtypene .ts og .tsx som finnes i katalogene src/ og test/

En merkelig feil 🐛

Siden ikke alt kan være perfekt i livet - endte vi opp med å få en merkelig feil etter konverteringen:

Det viser seg at på grunn av et ytelsesproblem med ESLint, må alle linede filer refereres fra tsconfig.json . Og det var .eslintrc.js selv som forårsaket problemet! Vi fikset dette ved å legge til en referanse til tsconfig.jsons "include"-array:

Rydder opp

Vi er nesten der! Nå trenger vi bare å fjerne den gamle tslint.json og opprette en Pull Request, og vi er i gang!

Konklusjon

Å migrere fra TSLint til ESLint var noe vi fortsatte å utsette inn i fremtiden, i frykt for at det ville bli en buggy og langvarig prosess. Takket være tslint-to-eslint-config var migreringen en lek, og vi måtte bare gjøre en rask feilretting for et prosjekt med over 80 000 linjer med TypeScript-kode.

Hvis du bestemmer deg for å ta på deg oppgaven med å migrere til ESLint – noe du definitivt burde – er disse trinnene du bør huske på:

1. Kjør tslint-to-eslint-config inne i prosjektets katalog.
2. Inspiser de nyopprettede reglene og juster dem for å møte kravene til prosjektet ditt.
3. Installer eventuelle ekstra avhengigheter som kreves for din spesifikke loprosess.
4. Koble ESLint til utviklingsverktøyene, CI og/eller byggeverktøyene dine.
5. Fjern de nå ubrukte TSLint-filene og trykk på endringene dine!

Lærepoeng 👩‍🏫

Å se på linting-oppsettet vårt på nytt minnet oss om viktigheten av linting og formatering – og deres rolle i en sunn utviklingsprosess.

Husk at linters ikke er ment å kontrollere formateringen av koden din, du bør bruke spesialiserte verktøy for begge: ESLint for linting og Prettier for eksempel for formatering.

Over tid har vi lært at linting-feil har en tendens til å krype tilbake i kodebasen. For å håndheve linting-reglene våre bør vi legge til et trinn for dem i CI-prosessen vår.

Til slutt har vi mange tilpassede regler som kan være vanskelige å opprettholde, så å holde seg til det anbefalte regelsettet fra ESLint ville være en god samtale.

Lykke til med koding!