Mi az npm? Csomópont csomagkezelő oktató kezdőknek

Ennek a cikknek a sok minden egyben nélkülözhetetlen útmutatójaként kell szolgálnia a Node.js kedvenc oldalkeresőjének: npm.

A Node.js 2009 óta rohamosan veszi a világot. A Node.js használatával több százezer rendszert építettek fel, ami arra késztette a fejlesztői közösséget, hogy állítsák: "a JavaScript megeszi a szoftvert".

A Node sikerének egyik fő tényezője az npm - a népszerű csomagkezelő, amely lehetővé teszi a JavaScript-fejlesztők számára, hogy gyorsan és egyszerűen megoszthassanak olyan hasznos csomagokat, mint a lodash és a moment.

Abban a pillanatban, amikor ezt a bejegyzést írom, az npm megkönnyítette több mint 1,3 millió csomag közzétételét, heti letöltési aránya meghaladja a 16 milliárdot! Ezek a számok fantasztikusak minden szoftvereszköz számára. Tehát most beszéljünk arról, hogy mi is pontosan az npm.

Mi az NPM?

Az NPM - vagy a "Node Package Manager" - az alapértelmezett csomagkezelő a JavaScript futásidejű Node.js fájljához.

Más néven "Ninja Pumpkin Mutants", "Nonprofit Pizza Makers" és számos más véletlenszerű név, amelyeket felfedezhet, és amelyekhez valószínűleg hozzájárulhat az npm-bővítések során.

Az NPM két fő részből áll:

  • egy CLI (parancssori felület) eszköz csomagok közzétételéhez és letöltéséhez, és
  • egy online tárhely, amely JavaScript csomagokat tárol

A vizuális magyarázat érdekében úgy gondolhatunk, hogy az npmjs.com adattár olyan teljesítési központ, amely áruk csomagjait fogadja eladóktól (npm csomag szerzők), és ezeket az árukat elosztja a vevőknek (npm csomag felhasználók).

Ennek a folyamatnak a megkönnyítése érdekében az npmjs.com teljesítési központ egy sereg szorgalmas vombatot (npm CLI) alkalmaz, akiket az egyes npmjs.com ügyfelek személyes asszisztensként jelölnek ki. Tehát a függőségeket az ilyen JavaScript-fejlesztők szállítják:

és egy csomag közzétételének folyamata a JS-társainak valami ilyesmi lehet:

Vizsgáljuk meg, hogyan segít ez a vombathadsereg azoknak a fejlesztőknek, akik JavaScript-csomagokat akarnak használni projektjeikben. Meglátjuk azt is, hogyan segítenek a nyílt forráskódú varázslóknak abban, hogy menő könyvtáraikat eljuttassák a világra.

csomag.json

Minden JavaScript-projekt - legyen az Node.js vagy böngészőalkalmazás - npm csomagként alkalmazható, saját csomagadatokkal és package.jsona projekt leírására szolgáló feladattal.

package.jsonBélyegzett címkékként gondolhatunk azokra az npm jó dobozokra, amelyeket Wombats seregünk szállít körbe.

package.jsonnpm inita JavaScript / Node.js projekt inicializálásához futtatáskor jön létre , a fejlesztők által biztosított alapvető metaadatokkal:

  • name: a JavaScript könyvtár / projekt neve
  • version: a projekt verziója. Gyakran előfordul, hogy az alkalmazásfejlesztés során ezt a mezőt gyakran elhanyagolják, mivel nincs nyilvánvaló szükség az opensource könyvtárak verziószámosítására. De mégis hasznos lehet a telepítés verziójának forrásaként.
  • description: a projekt leírása
  • license: a projekt engedélye

npm szkriptek

package.jsonegy olyan scriptstulajdonságot is támogat, amely meghatározható a projekt helyi kontextusába telepített parancssori eszközök futtatásához. Például scriptsegy npm projekt része így nézhet ki:

{ "scripts": { "build": "tsc", "format": "prettier --write **/*.ts", "format-check": "prettier --check **/*.ts", "lint": "eslint src/**/*.ts", "pack": "ncc build", "test": "jest", "all": "npm run build && npm run format && npm run lint && npm run pack && npm test" } } 

A eslint, prettier, ncc, jestnem feltétlenül telepíteni globális futtatható, hanem a helyi és a projekt belső node_modules/.bin/.

Az npx nemrégiben bevezetett verziója lehetővé teszi számunkra, hogy ezeket a node_modulesprojekt hatókörű parancsokat úgy futtassuk , mint egy globálisan telepített programot az előtaggal npx ...(azaz npx prettier --write **/*.ts).

függőségek vs devDependenciák

Ez a kettő kulcsérték-objektumok formájában jelenik meg, kulcsként npm könyvtárak neve és értékként szemantikai formátumú verzióik. Ez egy példa a Github TypeScript Action sablonjából:

{ "dependencies": { "@actions/core": "^1.2.3", "@actions/github": "^2.1.1" }, "devDependencies": { "@types/jest": "^25.1.4", "@types/node": "^13.9.0", "@typescript-eslint/parser": "^2.22.0", "@zeit/ncc": "^0.21.1", "eslint": "^6.8.0", "eslint-plugin-github": "^3.4.1", "eslint-plugin-jest": "^23.8.2", "jest": "^25.1.0", "jest-circus": "^25.1.0", "js-yaml": "^3.13.1", "prettier": "^1.19.1", "ts-jest": "^25.2.1", "typescript": "^3.8.3" } } 

Ezeket a függőségeket npm installa --saveés a --save-devflag használatával telepítik . Rendelkezésre állnak gyártási, illetve fejlesztési / tesztelési környezetben. A következő szakaszban részletesebben áttekintjük ezen csomagok telepítését.

Eközben fontos megérteni azokat a lehetséges jeleket, amelyek a szemantikai változatok elé kerülnek (feltételezve, hogy major.minor.patcha szemver modelljét elolvasta):

  • ^: legújabb kisebb kiadás. Például egy ^1.0.4specifikáció telepítheti a verziót, 1.3.0ha ez a legfrissebb legfrissebb kisebb verzió 1.
  • ~: legújabb patch kiadás. A ^kisebb verziókhoz hasonlóan a ~1.0.4specifikáció telepítheti a verziót, 1.0.7ha ez a 1.0kisebb sorozat legújabb kisebb verziója .

Ezeket a pontos csomagváltozatokat egy létrehozott package-lock.jsonfájl dokumentálja.

package-lock.json

Ez a fájl leírja az npm JavaScript projektben használt függőségek pontos verzióit. Ha package.jsonáltalános leíró címke, package-lock.jsonakkor összetevő táblázat.

És éppúgy, mint ahogyan általában nem olvassuk el a termék összetevőinek táblázatát (hacsak nem unod magad, vagy nem kell tudnod), package-lock.jsonnem is úgy értjük, hogy a fejlesztők soronként olvassák el őket (hacsak nem akarunk elkeseredetten megoldani " a gépemben működik "kérdések".

package-lock.jsonáltalában a npm installparancs generálja , és az NPM CLI eszközünk is elolvassa, hogy biztosítsa a projekt környezeti környezeteinek reprodukcióját npm ci.

Az NPM Wombats hatékony irányítása "vevőként"

Amint az a korábban említett 1,3 millió közzétett csomagból és a 16 milliárd letöltésből következik, az npm felhasználók többsége ebben az irányban használja az npm-et. Szóval jó tudni, hogyan kell ezt a hatékony eszközt használni.

npm telepítés

Ez a leggyakrabban használt parancs, mivel manapság JavaScript / Node.js alkalmazásokat fejlesztünk.

Alapértelmezés szerint npm install a csomag legújabb verzióját telepíti a ^verziószámmal. Egy npm installkeretében NPM projekt csomagokat fogja letölteni a projekt node_modulesmappa szerinti package.jsonelőírásoknak, korszerűsítése a csomag verziója (és viszont regeneráló package-lock.json), ahol csak lehet alapul ^és ~verziója megfelelő.

Megadhat globális jelzőt, -gha globális környezetben szeretne csomagot telepíteni, amelyet bárhol használhat a gépen (ez jellemző a parancssori eszközcsomagokra, például az élő szerverre).

Az npm olyan egyszerűvé tette a JavaScript-csomagok telepítését, hogy ezt a parancsot gyakran helytelenül használják. Ennek eredményeként az npm a sok programozói poén, mint ez:

Itt --productionjön a zászló a segítségre! Az előző részben, megbeszéltük dependenciesés devDependenciesazt jelentette a használat gyártása és fejlesztése / teszt környezetben rendre. Ez a --productionzászló teszi lehetővé a különbségeket node_modules.

Ha ezt a jelzőt a npm installparancshoz csatoljuk , akkor csak a (z) -tól fogunk telepíteni csomagokat dependencies, így drasztikusan csökkentjük a méretünket node_modules, bármennyire is feltétlenül szükségesek ahhoz, hogy alkalmazásunk működőképes legyen.

Ahogyan fiú- és lánycserkészként sem vittünk citromfacsarót a limonádéfülkénkbe, úgy ezt sem szabad devDependenciesgyártásba hoznunk !

npm ci

Tehát ha npm install --productionoptimális a termelési környezethez, akkor kell-e lennie egy parancsnak, amely optimális a helyi fejlesztéshez, a telepítés teszteléséhez?

A válasz npm ci.

Csakúgy, mint ha package-lock.jsonmég nem létezik a projektben, npm installamelyet npm cihíváskor generálnak , ezt a fájlt is felhasználja az egyes csomagok pontos verziójának letöltéséhez , amelytől a projekt függ.

This is how we can make sure that the our project's context stays exactly the same across different machines, whether it's our laptops used for development or CI (Continuous Integration) build environments like Github Actions.

npm audit

With the humongous number of packages that have been published and can easily be installed, npm packages are susceptible to bad authors with malicious intentions like these.

Realising that there was an issue in the ecosystem, the npm.js organisation came up with the idea of npm audit. They maintain a list of security loopholes that developers can audit their dependencies against using the npm audit command.

npm audit gives developers information about the vulnerabilities and whether there're versions with remediations to upgrade to. For example,

If the remediations are available in the next non-breaking version upgrades, npm audit fix can be used to upgrade the affected dependencies' versions automatically.

How to effectively command NPM wombats as "seller"

We have gone through how to wield the NPM CLI tool as a consumer, but what about effectively using it as an author (and potentially becoming a JavaScript open source wizard ?)?

npm publish

Sending a package to our npmjs.com fulfillment centre is super easy as we only need to run npm publish. The tricky part, which is not specific to npm package authors, is determining the version of the package.

The rule of thumb according to semver.org:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards compatible manner, and
  3. PATCH version when you make backwards compatible bug fixes.

It's even more important to follow the above rule when publishing your packages to ensure that you're not breaking anyone's code as the default version matching in npm is ^ (aka the next minor version).

❤️ npm ❤️ JavaScript ❤️ Node.js ❤️

That's all we need to know to start wielding npm effectively and command our lovely army of wombats!