Befri os fra afhængighed helvede

Befri os fra afhængighed helvede

de fleste moderne tjenester og applikationer har en masse afhængigheder, der lever i en stadigt voksende node-modules mappe. Generelt vedligeholdes, ændres og opdateres mange af disse biblioteker aktivt. Hvis dine afhængigheder er dårligt forvaltet, kan du hurtigt finde dig selv i afhængighed helvede.

hvis du ikke er bekendt med npm, skal du tjekke det ud her, før du læser på

krit Grocery Shopping

når du starter en node-applikation, kører et af de første trin npm install. Når du kører dette, vil node kontrollere for en fil kaldet package.json i bunden af dit projekt. Hvis denne fil er fundet, vil den bruge dependency sektionen som en slags “indkøbsliste” til at gå og samle “ingredienser” (kodebits), som din ansøgning kræver.
Alt tekst
“købmanden” i dette tilfælde er noget npm kalder en registry. Som standard vil din node-app se i det offentlige npm-register for disse pakker, hvor det meste alt, hvad du har brug for, vil være (private registre kan oprettes til proprietær kode og hvad ikke). Hvis pakken findes i registreringsdatabasen, sætter node den “ingrediens” i en node_modules mappe i bunden af dit projekt.

det er vigtigt at bemærke, at pakker, du har brug for, muligvis har deres egen “indkøbsliste” (pakke.JSON), og alle disse indlejrede afhængigheder skal løses, før din app går videre til den næste afhængighed i sin egen pakke.json.

alternativ tekst

⬆️ versioner, kareter og jokertegn

versionerne af dine afhængigheder er generelt noget i retning af v1.3.5. Dette kaldes semantisk versionering eller semver. Med semver repræsenterer tallene ændringer i koden i varierende sværhedsgrad – MAJOR.MINOR.PATCH.
fra deres dokumenter –

større version, når du foretager inkompatible API-ændringer,
mindre version, når du tilføjer funktionalitet på en bagudkompatibel måde, og
PATCH-version, når du laver bagudkompatible fejlrettelser.

med dette i tankerne vil mange mennesker automatisk opdatere deres app med nye nye ting, som deres afhængigheder måtte have i nyere, Ikke-breaking ændringer.

præfiks med tilde ~ vil give dig nye PATCH opdateringer, men ikke større eller mindre. Så ~1.3.1 kunne installere 1.3.9, men ikke 1.4.0

præfiks med caret ^ vil give dig nye PATCH og MINOR versioner, men ikke større. Så ^1.3.1 kunne installere 1.4.9 men ikke 1.5.0
Alt tekst
 Alt tekst

lad os se på vores eksempelkodes afhængighedstræ:

my-breakfast | | milk | |coffee-script 

okay, mere som en pind, men forhåbentlig er afhængighedskæden klar. Vores pakke.json kræver version v0.5.0 specifikt af milk, men mælk kræver coffee-script hvor som helst fra 0.9.61.0.0. npm install køres, vi udvikler vores app, alt er hunky-dory.

lad os nu spol frem 2 måneder. Nogen finder dit projekt og ønsker at bidrage. De gaffel og klone din repo, køre npm install, aaaaog det virker ikke. “Men det virkede på min maskine!”du græder. Da din samarbejdspartner installerede node-modulerne, blev de garanteret en bestemt version af milk, men de fik en anden version af coffee-scriptfordi milk ‘s pakke.json brugte semver.

Karl indstilling dine afhængigheder i sten

en løsning på dette er at bruge en package-lock.json fil. Denne fil giver dig meget detaljeret kontrol over versionerne af hver afhængighed, du installerer. Hvis din package.json er som indkøbslisten, så er din package-lock.json som et budget. Du kan få korn, men det bliver butiksmærke i stedet for Cap ‘ n Crunch. Denne specificitet løber helt ned ad hver gren af dit afhængighedstræ. Du skal have en package.json hvis du vil bruge en låsefil (package.json gør meget mere end bare afhængighedsstyring, det er bare fokus for dette indlæg).

liter indpakning

jeg føler personligt, at en package-lock.json fil altid skal bruges (i nyere versioner af npm genereres den faktisk automatisk). Det gør bare alt mere pålideligt på tværs af miljøer og implementeringer. Her er nogle sidste små nuggets, der forhåbentlig hjælper, når det kommer til afhængigheder:

  • npm install --save opdaterer automatisk din lockfile og pakke.Jens med den pakke.
  • npm ci i stedet for bare npm install vil automatisk genopbygge dine node moduler, og bygge fra din lockfile. Det er en virkelig nyttig kommando til CI/CD og generelt bedst at bruge sammen med en lockfile.
  • for større projekter, og super robust afhængighed, tjek docker og containere. Det kan fungere næsten som en virtuel maskine, der perfekt indeholder din kode, og det er afhængigheder, og er klonet for at fremme til forskellige miljøer. Så forhåbentlig ender du med meget mindre “det fungerede på min maskine” slags problemer.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.