Lever oss fra dependency hell

Lever oss fra dependency hell

de fleste moderne tjenester og applikasjoner har en masse avhengigheter som lever i en stadig voksende node-modules mappe. Generelt blir mange av disse bibliotekene aktivt vedlikeholdt, endret og oppdatert. Hvis avhengighetene dine er dårlig administrert, kan du raskt finne deg selv i avhengighets helvete.

hvis du ikke er kjent med npm, sjekk den ut her før du leser på

🛒 Dagligvarehandel

når du starter opp et nodeprogram, kjører et av de første trinnene npm install. Når du kjører dette, vil node se etter en fil som heter package.json i bunnen av prosjektet. Hvis den filen er funnet, vil den bruke delen dependency som en slags «handleliste» for å gå og samle «ingredienser» (kodebiter) søknaden din krever.
 Alternativ Tekst
«matbutikk» i dette tilfellet er noe npm kaller en registry. Som standard vil nodeappen din se i det offentlige npm-registeret for disse pakkene, der det meste du trenger vil være (private registre kan opprettes for proprietær kode og hva ikke). Hvis pakken er funnet i registret, setter node som «ingrediens» i en node_modules katalog på bunnen av prosjektet.

det er viktig å merke seg at pakker som du trenger kan ha sin egen «handleliste» (pakke.json), og alle de nestede avhengighetene må løses før appen din går videre til neste avhengighet i sin egen pakke.json.

Alternativ Tekst

⬆️ Versjoner, 🥕 Carets Og 🃏 Jokertegn

versjonene av avhengighetene dine er generelt noe som v1.3.5. Dette kalles semantisk versjonering, eller semver. Med semver representerer tallene endringer i koden i varierende alvorlighetsgrad – MAJOR.MINOR.PATCH.
fra sine dokumenter –

HOVEDVERSJON når du gjør inkompatible API-endringer,
UNDERORDNET versjon når du legger til funksjonalitet på en bakoverkompatibel måte, og
OPPDATERINGSVERSJON når du gjør bakoverkompatible feilrettinger.

med dette i tankene, mange mennesker ønsker å automatisk oppdatere sin app med noen friske nye ting deres avhengigheter kan ha i nyere, ikke-bryte endringer.

Prefiks med tilde ~ vil gi deg noen nye PATCH oppdateringer, men ikke større eller mindre. Så ~1.3.1 kunne installere 1.3.9, men ikke 1.4.0

Prefixing med caret ^ vil gi deg noen nye PATCH og MINOR versjoner, men ikke store. Så ^1.3.1 kunne installere 1.4.9 men ikke1.5.0
 Alt Tekst
 Alt Tekst

La oss ta en titt på vårt eksempel kode avhengighet treet:

my-breakfast | | milk | |coffee-script 

Ok, mer som en pinne, men forhåpentligvis er avhengighetskjeden klar. Vår pakke.json krever versjon v0.5.0 spesielt av milk, men melk krever coffee-script hvor som helst fra 0.9.61.0.0. npm install kjøres, vi utvikler vår app, alt er hunky-dory.

📼 la Oss nå spole fremover 2 måneder. Noen finner prosjektet ditt og ønsker å bidra. De gaffel og klone din repo, kjøre npm install, aaaaand det virker ikke. «Men det fungerte pa min maskin !»du gråter. Når samarbeidspartneren installerte nodemodulene, ble de garantert en bestemt versjon av milk, men de fikk en annen versjon av coffee-script fordi milk‘s pakke.json brukte semver.

🗿 Angi avhengigheter i stein

en løsning på dette er å bruke en package-lock.json fil. Denne filen gir deg veldig detaljert kontroll over versjoner av hver avhengighet som du installerer. Hvis din package.json er som handlelisten, er din package-lock.json som et budsjett. Du kan spise frokostblanding, men det blir butikkmerke i stedet For Cap ‘ n Crunch. Denne spesifisiteten går helt ned hver gren av avhengighetstreet ditt. Du må ha en package.json hvis du vil bruke en låsefil (package.json gjør mye mer enn bare avhengighetsadministrasjon, det er bare fokus for dette innlegget).

🎁 Innpakning

jeg føler personlig at en package-lock.json fil alltid skal brukes (i nyere versjoner av npm genereres den faktisk automatisk). Det gjør bare alt mer pålitelig på tvers av miljøer og distribusjoner. Her er noen siste små nuggets å forhåpentligvis hjelpe når det gjelder avhengigheter:

  • npm install --save vil automatisk oppdatere lockfile og pakke.jens med denne pakken.
  • npm ci i stedet for bare npm install vil automatisk gjenoppbygge node moduler, og bygge fra lockfile. Det er en veldig nyttig kommando FOR CI / CD og generelt best å bruke i tandem med en lockfile.
  • for større prosjekter, og super robust avhengighet, sjekk ut docker og containere. Det kan fungere nesten som en virtuell maskin som perfekt inneholder koden din og det er avhengigheter, og er klonet for å fremme til ulike miljøer. Så forhåpentligvis ender du med mye mindre» det fungerte på min maskin » slags problemer.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.