a legtöbb modern szolgáltatás és alkalmazás függőségek tömegével rendelkezik, amelyek egyre növekvő node-modules mappában élnek. Általában sok ilyen könyvtárat aktívan karbantartanak, módosítanak és frissítenek. Ha a függőségek rosszul kezelt, akkor gyorsan találja magát a függőség pokol.

ha nem ismeri az npm-et, nézze meg itt, mielőtt elolvassa a következő oldalt:

6157>

csomópont-alkalmazás indításakor az első lépések egyike a npm install futtatása. Amikor ezt futtatja, a node ellenőrzi a package.json nevű fájlt a projekt alapjában. Ha ez a fájl megtalálható, akkor a dependency szakaszt egyfajta “élelmiszerbolt-bevásárló listaként” fogja használni, hogy összegyűjtse az alkalmazás által igényelt “összetevőket” (kódbiteket).

az “élelmiszerbolt” ebben az esetben valami, amit az npm registry – nek hív. Alapértelmezés szerint a node alkalmazás a nyilvános npm nyilvántartásban fogja keresni ezeket a csomagokat, ahol a legtöbb minden, amire szüksége van (Privát nyilvántartások hozhatók létre a saját kódhoz stb.). Ha a csomag megtalálható a rendszerleíró adatbázisban, a node ezt az “összetevőt” egy node_modules könyvtárba helyezi a projekt alján.

fontos megjegyezni, hogy a szükséges csomagok saját “bevásárló listával” rendelkezhetnek (csomag.json), és az összes beágyazott függőséget meg kell oldani, mielőtt az alkalmazás a saját csomagjában a következő függőségre lép.json.

⬆️ a függőségek verziói általában

v1.3.5 – hoz hasonlóak . Ezt szemantikus verziózásnak vagy semvernek nevezik. A semver esetében a számok változó súlyosságú kódváltozásokat jelentenek – MAJOR.MINOR.PATCH.
a dokumentumokból –

főverzió, ha inkompatibilis API-módosításokat hajt végre,
kisebb verzió, ha visszafelé kompatibilis módon ad hozzá funkciókat, és
PATCH verzió, ha visszafelé kompatibilis hibajavításokat végez.

ezt szem előtt tartva, sok ember szeretné automatikusan frissíteni az alkalmazást minden friss új dolog a függőségek lehet, hogy újabb, nem törés változások.

Előtag tilde ~ kapsz minden új PATCH frissítéseket, de nem nagyobb vagy kisebb. Tehát ~1.3.1 lehet telepíteni 1.3.9, de nem 1.4.0

előtaggal caret ^ kapsz minden új PATCH és MINOR verzió, de nem nagyobb. Tehát ^1.3.1 Lehet telepíteni 1.4.9 de nem 1.5.0

vessünk egy pillantást a példakód függőségi fájára:

my-breakfast | | milk | |coffee-script 

Oké, inkább egy bot, de remélhetőleg a függőség lánca egyértelmű. A csomagunk.a json a v0.5.0 verziót igényli, konkrétan a milk – et, de a milk a coffee-script – ot igényli a 0.9.6 – 1.0.0 – tól. npm install fut, fejlesztjük app, minden hunky-dory.

6885 most ugorjunk előre 2 hónapot. Valaki megtalálja a projektet, és szeretne hozzájárulni. Ők villa és klón a repo, fuss npm install, aaaaés ez nem működik. “De a gépemen működött!”sírsz. Amikor a munkatárs telepítette a csomópont modulokat, garantálták nekik a milk adott verzióját, de a coffee-script másik verzióját kapták, mert a milkcsomagja.json használt semver.

6157>

az egyik megoldás erre a package-lock.json fájl használata. Ez a fájl nagyon részletes ellenőrzést biztosít minden telepített függőség verziói felett. Ha a package.json olyan, mint a bevásárló lista, akkor a package-lock.json olyan, mint egy költségvetés. Ehetsz müzlit, de bolti márka lesz a Cap ‘ n Crunch helyett. Ez a sajátosság végigfut a függőségi fa minden ágán. Meg kell egy package.json ha szeretné használni a lock fájlt (a package.json nem sokkal több, mint a függőség kezelése, ez csak a hangsúly ezen a poszton).

becsomagolás

személy szerint úgy érzem, hogy a package-lock.json fájlt mindig használni kell (az NPM újabb verzióiban valójában automatikusan generálódik). Ez mindent megbízhatóbbá tesz a környezetek és a telepítések között. Itt van néhány utolsó kis rögök, hogy remélhetőleg segíteni, amikor a dependecies:

• npm install --save automatikusan frissíti a zárfájlt és a csomagot.json azzal a csomaggal.
• npm ci ahelyett, hogy csak npm install automatikusan újraépíti a csomópont modulokat, és épít a lockfile. Ez egy nagyon hasznos parancs a CI / CD-hez, és általában a legjobb, ha egy lockfile-vel együtt használjuk.
• nagyobb projektek és szuper robusztus függőség esetén nézze meg a Dockert és a konténereket. Szinte úgy működik, mint egy virtuális gép, amely tökéletesen tartalmazza a kódot és a függőségeket, és klónozott, hogy elősegítse a különböző környezetekben. Tehát remélhetőleg a végén egy sokkal kevesebb” működött a gép ” fajta kérdések.