Ingen TypeScript. Ingen linter. Ingen Sentry. 170 lokasjoner bruker den hver dag.

Den nedarvede CRA-klientdelen var skrevet i ren JavaScript, uten TypeScript, ESLint, Prettier, Sentry, et gjenbrukbart komponentsystem eller en sammenhengende funksjonsstruktur. Den inneholdt mer enn 5 000 linjer med rå CSS, Tailwind-klasser overstyrt av innebygde stiler, kopierte sider og en flat mappestruktur.

Problemene forsterket hverandre. API-endringer nådde nettleseren uten tilbakemelding fra kompilatoren. Kopierte skjermflater gjentok de samme stilfeilene. Produksjonsfeil kom som regel gjennom brukerrapporter fordi det ikke fantes noen overvåkingskanal.

Applikasjonen betjente fortsatt 170 kundelokasjoner hver dag. Vi bygde ikke om V1 på stedet og ventet heller ikke på en fullstendig erstatning. De gamle rutene fortsatte å kjøre, mens hver ny V2-rute måtte oppfylle de nye standardene.

Det ga teamet en enkel regel: ikke utvid de gamle konvensjonene. Flytt eierskapet når en rute bygges om, og fjern den gamle banen når den nye kjører i produksjon.

• Joel Spolsky: Ting du aldri bør gjøre, del I

Next.js 15 og TypeScript dannet den nye yttergrensen. Nye ruter brukte typede rutedefinisjoner, genererte API-klienter, felles oppførsel for fetch og komponenter med en tydelig funksjonseier. Teamet konverterte ikke alle eldre filer først. Det sluttet å legge til nye flater uten typer og flyttet eierskapet inn i V2 etter hvert som arbeidet nådde hver rute.

• TypeScript og typede ruter gjorde feil i navigasjon og API-formater synlige under utviklingen.
• Genererte API-klienter og felles fetch-oppførsel erstattet spredte konvensjoner for forespørsler.
• Funksjonsmapper ga ruter, hooks, skjemaer og tester uttrykkelige eiere.
• Gjenbrukbare grunnelementer erstattet kopiert sidekode for gjentatte samhandlingsmønstre.

Moderniseringen endret også hvordan feil ble oppdaget og hvilke endringer som fikk slippe inn. Sentry la til rapportering fra klient, tjener og edge samt error boundaries i applikasjonen. Arbeidsflytene for enhets- og nettlesertester fikk uttrykkelige, påkrevde portjobber, mens atferdsbaserte tester dekket flyter med høy risiko, som Investor Intake.

Disse kontrollene reparerte ikke V1 automatisk. De gjorde hver V2-rute mulig å overvåke og teste før den overtok mer ansvar i produksjon.

• Se hvordan produksjonsfeil ble gjort lesbare med Sentry
• Se hvordan påkrevde CI-porter sørget for at testene kjørte

V2 eide den felles siderammen, autentiseringen og hver nylig migrerte funksjon. CRA lå bare i én iframe for rutene den fortsatt eide. Den tilhørende migreringsartikkelen beskriver broen for postMessage, SSO og ruting i detalj.

Det viktige i denne artikkelen er eierskap: de nye standardene gjaldt ved V2-grensen, og hver fullførte migrering reduserte mengden kode som var unntatt fra dem.

Eierskapet ble fulgt uttrykkelig gjennom overgangen. Navbar, Topbar, Settings, Investor Intake, Authentication og Twilio flyttet til V2. Home, Genius Mode, Deals og Buyers ble i V1 til erstatningene var klare. Kundelokasjonene ble flyttet i kontrollerte grupper i stedet for å få alle uferdige flater samtidig.

Denne oversikten hindret omskrivingen i å bli et uavgrenset parallelt prosjekt. En funksjon var enten fortsatt eid av V1, levert gjennom kompatibilitetsgrensen eller bygd direkte i V2.

Den endelige overgangen fjernet iframe-en, de eldre genererte API-klientene og brokoden. Deretter ble foreldede ruter, tester, autentiseringsvakter, delt oppringingskode og komponentstrukturen ryddet opp. Moderniseringen var ikke ferdig før den midlertidige grensen kunne slettes.

• Ikke mål fremdrift i antall nyopprettede rammeverksfiler.
• Mål hvilke ansvarsområder i produksjon som er flyttet, og hvilke kompatibilitetsbaner som kan fjernes.
• La ny kode følge de nye standardene i stedet for å vente på en perfekt konvertering av hele kodebasen.
• Slett den midlertidige migreringsinfrastrukturen når den siste avhengige flaten er flyttet.