Första hjälpen för trasiga JavaScript-beroenden

Jag skulle vilja skriva om JavaScript beroenden. Men låt oss börja från början. Om du är programvaruutvecklare vet du säkert redan att en av dina många roller definitivt inte är att vara ännu en hjuluppfinnare. Åtminstone inte i de flesta fall. Världen har gått så långt att det idag finns paket för nästan allt, vilket gör vår utveckling enklare och mer effektiv.

Detta är naturligtvis inte en uppmuntran till att tappa intresset för andra frågor - varje paket har ett ganska stort utrymme för att förbättras och utvecklas. Ditt affärsmål är dock att ta fram ett komplett Produkt på en tallrik precis i tid eller till och med innan den är uppe. Förpackningar hjälper dig att uppfylla dessa planer och ger npm eller Garn på toppen av dina bästa vänners lista, men var medveten om: alla lösningar, liksom den här, kan också medföra risker. Och vi kommer att försöka beskriva det och visa dig ett bättre sätt att komma undan med det i artikeln nedan.

Låt oss börja med en berättelse...

Föreställ dig en stor JavaScript projekt. Affärskrav tvingar utvecklare att använda ett specifikt paket, vilket möjliggör en korrekt integration med ett annat system hos en kund. Och det är helt okej. MVP har levererats i tid, nästa kontrakt har tecknats och utvecklingen fortsätter. Kunden ber att få integrera nästa del av ett system, vilket kräver en uppdatering av ditt paket.

Denna del går bra, tills testerna avfyras. Det verkar som om paketet innehåller en enkel, men obekväm bugg, som ännu inte har åtgärdats i någon produktversion och det är känt att detta inte kommer att ske tillräckligt snart. Du kan inte bara fixa din nod_moduler katalog - bör det tas bort från ditt arkiv från spårning, därför kommer dina medarbetare aldrig att veta något om dina ändringar! Tja, medan du läste detta har du förmodligen redan förstått vad du ska göra - fork. Men behöver du verkligen en sådan hammare?

Förstå ditt problem

Du måste vara medveten om huruvida det problem du står inför kommer att beröra bara dig eller en större grupp. Ibland tolkar människor avsaknad av viss funktionalitet som en bugg, vilket inte alltid är korrekt. Det är därför, din lösning kanske inte accepteras av en community och inte inkluderas i en officiell repository. Men du behöver det fortfarande här och nu. Nåväl, låt oss lappa ihop det!

Enligt release notes från github repository, patch-package ) släpptes officiellt i maj 2017. It är ett kraftfullt verktyg som gör det möjligt att installera ändringar i beroendeprojektet i din nod_moduler katalog. Vissa kanske säger att detta är ganska galenskap - avfyrningsinstallationskommando din beroendehanterare kommer att skriva över ändringarna.

Detta är korrekt. Men ett patch-paket samexisterar med npm och Garn perfekt (jag måste erkänna att det fungerar något bättre med npm hittills, du kan läsa mer i avsnittet "Varför ska du använda postinstall-prepare med Yarn?" i README-filen) och drar full nytta av en skriptförberedelse ("script": {"prepare":""}) av din paket.json fil. Patch-package skapar bokstavligen en diff-katalog mellan dina ändringar och originalpaketet, som lagras i patch-mappen i ditt faktiska projekt.

När kommandot install har körts och alla beroenden har laddats ner tillämpas skillnaden i projektkatalogen, vilket ger en perfekt rekonstruktion av dina ändringar för alla samarbetspartners. Det gör ditt liv enklare, eller hur? Lösningen har också vissa nackdelar. Patch-paketet kan inte fixa beroenden av ditt paket eller göra några ändringar i paket.json.

I det här fallet kan du använda fork-lösningen. Du måste också överväga antalet ändringar som du är på väg att göra i ditt beroendepaket och om de kommer att växa med tiden. Om så är fallet bör du tänka dig noga för när du använder fork, eftersom det här är ett eget projekt.

Var inte självisk!

Patching är ett bra sätt att fixa dina beroenden utan att skapa oändliga forks och generera flera projektkällor. Men du bör alltid komma ihåg att det inte bara ska vara enkelriktat att dra nytta av communityt. Om du hittar en bugg eller känner att du kan förbättra det paket du använder, bör du alltid överväga att hjälpa andra genom att registrera ett problem eller till och med genom att bidra till projektet!