Førstehjælp til ødelagte JavaScript-afhængigheder

Jeg vil gerne skrive om JavaScript afhængigheder. Men lad os starte fra begyndelsen. Hvis du er softwareudvikler, så ved du sikkert allerede, at en af dine mange roller bestemt ikke er at være endnu en hjulopfinder. I hvert fald ikke i de fleste tilfælde. Verden er kommet så langt, at der i dag findes pakker til næsten alt, som gør vores udvikling nemmere og mere effektiv.

Det er selvfølgelig ikke en opfordring til at miste interessen for andre emner - hver pakke har et ret stort rum til at forbedre og udvikle sig. Men dit forretningsmæssige mål er at bringe en komplet produkt på en tallerken lige til tiden eller endda før den er oppe. Pakker hjælper dig med at opfylde disse planer og bringer npm eller Garn på toppen af dine bedste venners liste, men vær opmærksom på, at enhver løsning, også denne, også kan indebære en risiko. Og vi vil forsøge at beskrive det og vise dig en bedre måde at slippe af sted med det på i artiklen nedenfor.

Lad os begynde med en historie...

Forestil dig en stor JavaScript projekt. Forretningskrav forpligter udviklere til at bruge en bestemt pakke, der giver mulighed for en ordentlig integration med et andet system hos en kunde. Og det er helt i orden. MVP er blevet leveret til tiden, den næste kontrakt er blevet underskrevet, og udviklingen fortsætter. Kunden beder om at få integreret den næste del af et system, som kræver en opdatering af din pakke.

Denne del går godt, indtil testene går i gang. Det ser ud til, at pakken indeholder en simpel, men ubelejlig fejl, som endnu ikke er blevet rettet i nogen produktudgivelse, og man ved, at det ikke vil ske hurtigt nok. Du kan ikke bare fikse din node_moduler Katalog - skal den fjernes fra dit repository, så dine samarbejdspartnere aldrig får noget at vide om dine ændringer! Mens du læste dette, har du sikkert allerede forstået, hvad du skal gøre - fork. Men har du virkelig brug for sådan en hammer?

Forstå dit problem

Du skal være opmærksom på, om det problem, du står over for, kun involverer dig eller et større fællesskab. Nogle gange fortolker folk manglende funktionalitet som en fejl, hvilket ikke altid er korrekt. Det er derfor, din løsning bliver måske ikke accepteret af et fællesskab og ikke inkluderet i et officielt repository. Men du har stadig brug for den her og nu. Så lad os lappe den!

Ifølge udgivelsesnoterne fra github-arkivet er patch-pakken ) blev officielt udgivet i maj 2017. It er et stærkt værktøj, der gør det muligt at installere ændringer i afhængighedsprojektet i din node_moduler Katalog. Nogle vil måske sige, at det er helt vanvittigt - når du affyrer installationskommandoen, vil din afhængighedsmanager overskrive ændringerne.

Ja, det er korrekt. Men en patch-pakke eksisterer side om side med npm og Garn perfekt (jeg må indrømme, at det fungerer lidt bedre med npm indtil videre, du kan læse mere i afsnittet "Hvorfor skal du bruge postinstall-prepare med Yarn?" i README-filen) og drager fuld fordel af en scriptforberedelse ("script": {"prepare":""}) af din pakke.json fil. Patch-package opretter bogstaveligt talt en differensmappe mellem dine ændringer og den oprindelige pakke, som gemmes i patch-mappen i dit egentlige projekt.

Når du har kørt kommandoen install og downloadet alle afhængigheder, anvender den forskellen i projektmappen og laver en perfekt rekonstruktion af dine ændringer for alle samarbejdspartnere. Det gør dit liv enklere, ikke sandt? Løsningen har også nogle ulemper. Patch-pakken kan ikke rette afhængigheder af din pakke eller foretage ændringer i pakke.json.

I dette tilfælde kan du bruge fork-løsningen. Du skal også overveje, hvor mange ændringer du er ved at lægge ind i din afhængighedspakke, og om de vil vokse med tiden. Hvis det er tilfældet, skal du tænke dig godt om, når du bruger fork, da det er dit eget projekt.

Lad være med at være egoistisk!

Patching er en god måde at rette dine afhængigheder på uden at skabe endeløse forks og generere flere projektkilder. Men du skal altid huske, at det ikke kun bør gå én vej, når du udnytter fællesskabet. Hvis du finder en fejl eller føler, at du kan forbedre den pakke, du bruger, bør du altid overveje at hjælpe andre ved at registrere et problem eller endda ved at bidrage til projektet!