Eerste hulp bij kapotte JavaScript afhankelijkheden

Ik wil graag schrijven over JavaScript afhankelijkheden. Maar laten we bij het begin beginnen. Als je softwareontwikkelaar bent, dan weet je waarschijnlijk al dat een van je vele rollen beslist niet de zoveelste wieluitvinder is. Tenminste, niet in de meeste gevallen. De wereld is ver genoeg gevorderd om te zeggen dat er tegenwoordig pakketten bestaan voor bijna alles, wat onze ontwikkeling gemakkelijker en efficiënter maakt.

Dit is natuurlijk geen aanmoediging om je interesse in andere zaken te verliezen - elk pakket heeft een vrij grote ruimte om te verbeteren en te evolueren. Je bedrijfsdoel is echter om een compleet product op een bord precies op tijd of zelfs voordat het op is. Pakketten helpen je om die plannen uit te voeren en brengen npm of garen bovenaan het lijstje van je beste vrienden, maar let op: elke oplossing, ook deze, kan ook risico's met zich meebrengen. En we zullen proberen het te beschrijven en je een betere manier laten zien om ermee weg te komen in het onderstaande artikel.

Laten we beginnen met een verhaal...

Stel je een grote JavaScript voor project. Zakelijke vereisten verplichten ontwikkelaars om een specifiek pakket te gebruiken dat een goede integratie met een ander systeem van een klant mogelijk maakt. En dat is helemaal prima. MVP op tijd is gebracht, het volgende contract is getekend en de ontwikkeling gaat door.. De klant vraagt om het volgende deel van een systeem te integreren, waarvoor uw pakketupdate nodig is.

Dit deel gaat goed, totdat de tests worden uitgevoerd. Het lijkt erop dat het pakket een eenvoudige, maar onhandige bug bevat, die nog in geen enkele productrelease is opgelost en het is bekend dat dit niet snel genoeg zal gebeuren. Je kunt je knooppuntmodules map - zou het uit je repository verwijderd moeten worden van tracking, daarom zullen je medewerkers nooit iets weten van je wijzigingen! Nou, terwijl je dit las, heb je waarschijnlijk al begrepen wat je moet doen - fork. Maar heb je echt zo'n hamer nodig?

Uw probleem begrijpen

Je moet je ervan bewust zijn of het probleem waar je mee te maken hebt alleen betrekking heeft op jou of op een grotere gemeenschap. Soms interpreteren mensen het ontbreken van bepaalde functionaliteit als een bug, wat niet altijd correct is. Daarom, jouw oplossing wordt mogelijk niet geaccepteerd door een community en niet opgenomen in een officieel archief. Maar je hebt het nog steeds hier en nu nodig. Nou, laten we het oplappen!

Volgens de release notes van de github repository, patch-pakket ) werd officieel uitgebracht in mei 2017. It is een krachtig hulpprogramma waarmee wijzigingen binnen een afhankelijkheidsproject kunnen worden geïnstalleerd in je knooppuntmodules map. Sommigen zullen zeggen dat dit nogal gek is - door het installatiecommando te vuren zal je afhankelijkheidsbeheerder de wijzigingen overschrijven.

Nou, dit is correct. Een patchpakket bestaat echter naast npm en garen perfect (ik moet toegeven dat het tot nu toe iets beter werkt met npm, je kunt meer lezen in "Waarom je postinstall-prepare zou moeten gebruiken met Yarn?" sectie van het README-bestand) en maakt optimaal gebruik van een scriptvoorbereiding ("script": {"prepare":""}) van je pakket.json bestand. Patch-pakket maakt letterlijk een diff map aan tussen jouw wijzigingen en het originele pakket, opgeslagen in de patch map van je eigenlijke project..

Na het uitvoeren van het installatiecommando en het downloaden van alle afhankelijkheden, past het dat verschil toe op de projectmap en maakt het een perfecte reconstructie van je wijzigingen voor alle medewerkers. Het maakt je leven eenvoudiger, nietwaar? De oplossing heeft ook enkele nadelen. Het patchpakket kan geen afhankelijkheden van je pakket repareren of wijzigingen aanbrengen in pakket.json.

In dit geval kunt u de fork-oplossing gebruiken. Je moet ook rekening houden met het aantal wijzigingen dat je gaat toepassen in je afhankelijkheidspakket en of ze in de loop van de tijd zullen groeien. In het geval van wel - moet je goed nadenken bij het gebruik van fork, aangezien dit een project van jezelf is.

Wees niet egoïstisch!

Patchen is een geweldige manier om je afhankelijkheden te repareren zonder eindeloze forks aan te maken en meerdere projectbronnen te genereren. Maar je moet altijd onthouden dat het profiteren van de gemeenschap geen eenrichtingsverkeer moet zijn. Als je een bug vindt of het gevoel hebt dat je het pakket dat je gebruikt kunt verbeteren, moet je altijd overwegen om anderen te helpen door een probleem te registreren of zelfs door bij te dragen aan het project!