Delivery us from dependency hell

Delivery us from dependency hell

de meeste moderne diensten en toepassingen hebben een massa afhankelijkheden die in een steeds groeiende node-modules map leven. Over het algemeen worden veel van deze bibliotheken actief onderhouden, gewijzigd en bijgewerkt. Als je afhankelijkheden slecht worden beheerd, kun je je snel in de afhankelijkheidshel bevinden.

als u niet bekend bent met npm, check het hier voordat u leest op

🛒 boodschappen doen

bij het opstarten van een knooppunttoepassing draait een van de eerste stappen npm install. Wanneer u dit uitvoert, zal node controleren op een bestand met de naam package.json in de basis van uw project. Als dat bestand gevonden wordt, zal het de dependency sectie gebruiken als een soort “boodschappenlijst” om “ingrediënten” (code bits) te verzamelen die uw toepassing nodig heeft.
Alt tekst
de “kruidenierswinkel” is in dit geval iets wat npm een registrynoemt. Standaard zal uw node-app in het publieke NPM-register kijken voor deze pakketten, waar het meeste wat je nodig hebt zal zijn (private registers kunnen worden gemaakt voor propriëtaire code en wat al niet). Als het pakket in het register wordt gevonden, plaatst node dat “ingrediënt” in een node_modules map aan de basis van uw project.

het is belangrijk op te merken dat pakketten die u nodig heeft hun eigen “boodschappenlijst” (pakket.json), en al die geneste afhankelijkheden moeten worden opgelost voordat uw app gaat naar de volgende afhankelijkheid in zijn eigen pakket.json.

Alt-tekst

⬆️ versies , care Carets, en wild Wildcards

de versies van uw afhankelijkheden zijn over het algemeen ongeveer v1.3.5. Dit wordt semantische versievorming of semver genoemd. Bij semver vertegenwoordigen de getallen veranderingen in de code in verschillende ernst – MAJOR.MINOR.PATCH.
uit hun documenten –

hoofdversie wanneer u incompatibele API-wijzigingen aanbrengt,
kleine versie wanneer u functionaliteit op een achterwaarts compatibele manier toevoegt, en
patchversie wanneer u achterwaarts compatibele bugfixes maakt.

met dit in gedachten willen veel mensen hun app automatisch updaten met nieuwe dingen die hun afhankelijkheden zouden kunnen hebben in nieuwere, Niet-afbrekende wijzigingen.

Prefixing met tilde ~ geeft u alle nieuwe PATCH updates, maar niet major of minor. Dus ~1.3.1 kan 1.3.9 installeren, maar niet 1.4.0

Prefixing met caret ^ geeft u alle nieuwe PATCH en MINOR versies, maar niet major. Dus ^1.3.1 kan 1.4.9 installeren maar niet 1.5.0
alt-tekst
Alt-tekst

laten we eens kijken naar onze voorbeeld code ‘ s dependency tree:

my-breakfast | | milk | |coffee-script 

Ok, meer als een stok, maar hopelijk is de keten van afhankelijkheid duidelijk. Ons pakketje.json vereist specifiek versie v0.5.0 van milk, maar melk vereist coffee-script overal van 0.9.61.0.0. npm install wordt uitgevoerd, We ontwikkelen onze app, alles is perfect.

📼 laten we nu 2 maanden vooruitspoelen. Iemand vindt uw project en wil bijdragen. Ze forken en klonen je repo, draaien npm install, AAAA en het werkt niet. “Maar het werkte op mijn machine!”je huilt. Toen uw medewerker de knooppuntmodules installeerde, kregen ze gegarandeerd een specifieke versie van milk, maar kregen ze een andere versie van coffee-script vanwege het pakket van milk.json gebruikte semver.

🗿 uw afhankelijkheden instellen in stone

een oplossing hiervoor is het gebruik van een package-lock.json bestand. Dit bestand geeft je zeer gedetailleerde controle over de versies van elke afhankelijkheid die je installeert. Als uw package.json gelijk is aan de boodschappenlijst, dan is uw package-lock.json een soort budget. Je mag cornflakes hebben, maar het wordt een winkelmerk in plaats van Cap ‘ n Crunch. Deze specificiteit loopt helemaal door elke tak van je afhankelijkheidsboom. U moet een package.json hebben als u een lock-bestand wilt gebruiken (de package.json doet veel meer dan alleen afhankelijkheidsbeheer, dat is slechts de focus van dit bericht).

🎁 inpakken

persoonlijk vind ik dat een package-lock.json bestand altijd gebruikt moet worden (in nieuwere versies van npm wordt het eigenlijk automatisch gegenereerd). Het maakt alles gewoon betrouwbaarder in omgevingen en implementaties. Hier zijn een aantal laatste kleine nuggets om hopelijk te helpen als het gaat om dependecies:

  • npm install --save zal automatisch uw lockfile en pakket bijwerken.json met dat pakje.
  • npm ci in plaats van slechts npm install zal automatisch uw knooppuntmodules herbouwen en bouwen vanuit uw lockfile. Het is een zeer nuttig commando voor CI / CD en over het algemeen het beste om te gebruiken in combinatie met een lockfile.
  • voor grotere projecten, en super robuuste afhankelijkheid, check out docker en containers. Het kan bijna functioneren als een virtuele machine die perfect uw code en zijn afhankelijkheden bevat, en is gekloond om te bevorderen naar verschillende omgevingen. Dus hopelijk eindig je met een stuk minder” het werkte op mijn machine ” soort problemen.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.