Førstehjelp for ødelagte JavaScript-avhengigheter

Jeg vil gjerne skrive om JavaScript avhengigheter. Men la oss starte fra begynnelsen. Hvis du er programvareutvikler, så vet du sannsynligvis allerede at en av dine mange roller definitivt ikke er å være enda en hjuloppfinner. I hvert fall ikke i de fleste tilfeller. Verden har gått så langt at det i dag finnes pakker for nesten alt, noe som gjør utviklingen vår enklere og mer effektiv.

Dette er selvfølgelig ikke en oppfordring til å miste interessen for andre spørsmål - hver pakke har et ganske stort rom for forbedring og utvikling. Forretningsmålet ditt er imidlertid å bringe en komplett produkt på et fat akkurat i tide eller til og med før det er oppe. Pakker hjelper deg med å oppfylle disse planene, og gir npm eller garn på toppen av listen over dine beste venner, men vær oppmerksom på: enhver løsning, så vel som denne, kan også medføre risiko. Og vi vil prøve å beskrive det og vise deg en bedre måte å komme unna med det i artikkelen nedenfor.

La oss begynne med en historie...

Forestill deg en stor JavaScript prosjekt. Forretningskrav forplikter utviklere til å bruke en spesifikk pakke, slik at det blir mulig å integrere med et annet system hos en klient. Og det er helt i orden. MVP er levert i tide, neste kontrakt er signert og utviklingen fortsetter. Kunden ber om å integrere neste del av et system, noe som krever en oppdatering av pakken din.

Denne delen går bra, helt til testene blir avfyrt. Det ser ut til at pakken inneholder en enkel, men upraktisk feil, som ennå ikke har blitt rettet i noen produktutgivelse, og det er kjent at dette ikke vil skje snart nok. Du kan ikke bare fikse din node_moduler katalog - skal den fjernes fra depotet ditt fra sporing, og derfor vil samarbeidspartnerne dine aldri få vite noe om endringene dine! Vel, mens du leste dette, har du sannsynligvis allerede forstått hva du skal gjøre - fork. Men trenger du virkelig en slik hammer?

Forstå problemet ditt

Du må være klar over om problemet du står overfor, kommer til å involvere bare deg eller et større fellesskap. Noen ganger tolker folk manglende funksjonalitet som en feil, noe som ikke alltid er riktig. Det er derfor viktig, løsningen din blir kanskje ikke akseptert av et fellesskap og ikke inkludert i et offisielt repositorium. Men du trenger det fortsatt her og nå. Vel, la oss lappe den sammen!

I følge utgivelsesmerknadene i github-depotet, patch-pakke ) ble offisielt utgitt i mai 2017. It er et kraftig verktøy som gjør det mulig å installere endringer i avhengighetsprosjektet i din node_moduler katalog. Noen vil kanskje si at dette er ganske galskap - skyte installere kommandoen din avhengighet manager vil overskrive endringene.

Vel, dette er riktig. En patch-pakke eksisterer imidlertid sammen med npm og garn perfekt (jeg må innrømme at det fungerer litt bedre med npm så langt, du kan lese mer i "Hvorfor bør du bruke postinstall-prepare med Yarn?"-delen av README-filen) og drar full nytte av en skriptforberedelse ("script": {"prepare":""}) av din package.json fil. Patch-package oppretter bokstavelig talt en diff-katalog mellom endringene dine og den opprinnelige pakken, som lagres i patch-mappen i det faktiske prosjektet ditt.

Etter at du har kjørt install-kommandoen og lastet ned alle avhengigheter, bruker den forskjellen i prosjektkatalogen og lager en perfekt rekonstruksjon av endringene dine for alle samarbeidspartnere. Det gjør livet ditt enklere, ikke sant? Løsningen har også noen ulemper. Patch-pakken kan ikke fikse avhengigheter til pakken din eller gjøre endringer i package.json.

I dette tilfellet kan du bruke gaffelløsningen. Du må også vurdere hvor mange endringer du er i ferd med å legge inn i avhengighetspakken din, og om de vil vokse med tiden. Hvis det er tilfelle, bør du tenke deg nøye om når du bruker fork, siden dette er ditt eget prosjekt.

Ikke vær egoistisk!

Patching er en flott måte å fikse avhengigheter på uten å skape endeløse forker og generere flere prosjektkilder. Men du bør alltid huske at det å dra nytte av fellesskapet ikke bare bør gå i én retning. Hvis du finner en feil eller føler at du kan forbedre pakken du bruker, bør du alltid vurdere å hjelpe andre ved å registrere et problem eller til og med ved å bidra til prosjektet!