Als u de score bijhoudt, hebben we tot nu toe in deze npm-gids een algemeen begrip ontwikkeld van wat npm is, met name dat het staat voor Node Package Manager. Tijdens het proces hebben we het belang van de opdrachtregel besproken en hoe deze wordt gebruikt met npm.

We hebben ook specifiek gekeken naar de "n" in npm - Node - en ontdekten dat Node veel lijkt op de JavaScript-code die we schrijven om op websites in een browser te draaien. In feite, Knooppunt is javascript; het draait gewoon buiten de browser en kan andere dingen doen dan zijn browsergebaseerde tegenhanger.

Gidshoofdstukken

1. Wie is dit in godsnaam? Gids Voor?
2. Wat betekent 'npm' in vredesnaam?
3. Wat is in godsnaam de opdrachtregel?
4. Wat is in godsnaam Node?
5. Wat is in godsnaam een ​​pakketbeheerder? (Je bevindt je hier!)
6. Hoe installeer je in vredesnaam npm?
7. Hoe installeer je in vredesnaam npm-pakketten?
8. Wat zijn in godsnaam npm-opdrachten?
9. Hoe installeer je in vredesnaam een ​​bestaand npm-project?

Wat bedoelen we met "pakket"

Laten we nu onze aandacht richten op de laatste twee letters in npm, namelijk het gedeelte “pakketbeheerder”. Om volledig te begrijpen wat npm is, moeten we weten wat een pakketbeheerder is. Dus het volgt natuurlijk dat om te begrijpen dat, moeten we begrijpen wat in godsnaam een ​​"pakket" is.

"Pakket” is een verzamelnaam voor alle externe codebestanden die u in een project haalt en op de een of andere manier gebruikt. Misschien heb je gebruikt jQuery, Bootstrapof Axios op een project in het verleden. Dat zijn veelvoorkomende voorbeelden van pakketten.

We noemen deze 'pakketten' omdat ze 'ingepakt' zijn en klaar voor gebruik. Sommige talen noemen ze bij andere namen (Ruby noemt ze bijvoorbeeld 'edelstenen'), maar het concept is hetzelfde. Op het gevaar af te simplificeren, a pakket is code die je niet hebt geschreven maar van een openbare bron hebt gekregen om in je project te gebruiken. Je weet wel, code van derden.

Of, als je de voorkeur geeft aan muzikale parodieën voor je geheugensteuntjes:

???? Wanneer er een code is die u kiest
???? Dat is niet van jou, maar je gebruikt
???? Dat is een pakket
???? Als het dingen zijn die je installeert
???? Dat je importeert en belt,
???? Dat is een pakket

Pakketten worden ook vaak "afhankelijkheden" genoemd, omdat de code die u schrijft afhankelijk op hun aanwezigheid. Code geschreven met jQuery's $ zal niet goed werken als jQuery zelf bijvoorbeeld nog niet is geladen. (Om deze reden worden pakketbeheerders soms ook "afhankelijkheidsmanagers" genoemd.)

Pakketten kunnen groot of klein zijn in termen van hoeveel code ze bevatten. Een pakket kan iets enorms doen dat de manier waarop je je hele project schrijft verandert (zoals een heel raamwerk), of het kan iets heel kleins en gerichts doen dat je alleen instrooit waar nodig (zoals een widget of een helper voor een specifieke taak) .

Pakketten gebruiken zonder pakketbeheerder

Hoogstwaarschijnlijk, als u in het verleden een pakket heeft gebruikt, heeft u het eenvoudigweg toegepast met een scripttag in de HTML die van een externe URL haalt (idealiter van een CDN). Zo kunt u jQuery opnemen in de HTML van uw site:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>

Een andere benadering is om een ​​kopie van het pakket te downloaden, het toe te voegen aan de bestanden van uw project en er lokaal naar te linken, zoals dit:

<script src="/jquery.min.js"></script>

Wat pakketbeheerders oplossen?

Deze twee benaderingen werken al jaren goed. Het is makkelijk. Het is schoon. Het laat je over het algemeen "instellen en vergeten" voor zover het pakket gaat. Dus waarom zou je iets anders nodig hebben?

U kunt zich waarschijnlijk voorstellen hoe het bezit van een auto onaantrekkelijk lijkt voor iemand die gemakkelijk toegang heeft tot gemakkelijk vervoer of die geen lange afstanden hoeft te reizen. (Dit sluit weer aan bij het gesprek met de pakketbeheerder, dat beloof ik. Blijf bij me.)

Als je gemakkelijk toegang hebt tot handig en efficiënt openbaar vervoer, dan zal het betalen van een hoge prijs voor een enorme machine die je ergens moet opslaan, regelmatig moet schoonmaken, onderhouden en vullen met dure brandstof, vanuit jouw perspectief waarschijnlijk niet veel voordeel opleveren. In dat specifieke geval zijn de voordelen verwaarloosbaar; de kosten zijn relatief overweldigend. Iemand in die hypothetische positie zou zich zelfs kunnen afvragen waarom iemand überhaupt een auto wil!

Ik breng deze analogie naar voren omdat het erg moeilijk kan zijn om over een nieuwe technologie te leren wanneer het lost een probleem op dat je niet hebt, op vrijwel dezelfde manier dat het kopen van een auto het transport dat u al heeft misschien niet oplost. Het lijkt misschien een enorme, onnodige uitgave.

Wat een pakketbeheerder oplost, is dus meer een kwestie van schaalvergroting en het afhandelen van zorgen. Eenvoudig linken naar een pakket in een scripttag werkt goed, zolang:

• het aantal projecten dat je hebt is beheersbaar;
• het aantal mensen dat aan de projecten werkt is beheersbaar;
• het aantal updates dat gedaan moet worden aan de pakketten is beheersbaar; en, belangrijker nog,
• elk pakket dat in uw projecten wordt gebruikt, is client-side (browser) JavaScript of CSS.

Die laatste is de doozy, want er is een overvloed aan gereedschappen die je nooit kunt gebruiken als je Slechts voer dingen uit in de browser (daarover straks meer).

als u do vink al die vakjes aan, je zult deze aanpak misschien nooit ontgroeien. Uw ontwikkelingsaanpak zou er zo uit kunnen zien:

Maar zelfs in dat geval, wanneer u meerdere <script> tags, die elk verwijzen naar een specifieke versie van een script of bibliotheek, de Slechts manier om enig inzicht te krijgen in welke pakketten je gebruikt - en of ze up-to-date zijn - is om handmatig de HTML te openen en naar de code te kijken.

Dat is op zich niet zo'n probleem, maar het is een probleem dat exponentieel groeit naarmate de omvang en reikwijdte van een project toenemen. U kunt misschien een paar pakketten handmatig bijhouden, maar hoe zou u dat kunnen doen als we het hebben over honderden, zo niet duizenden, pakketten? En zelfs als je die handmatig zou kunnen volgen, brengt dat nog steeds een hoog risico op menselijke fouten met zich mee.

Het is niet de taak van HTML om de bron van waarheid te zijn voor alle pakketten die in een project worden gebruikt. Afgezien van het mengen van zorgen, introduceert het mogelijk ook conflicten bij het samenvoegen van niet-gerelateerd werk tussen teamgenoten.

Dit is allemaal belangrijk, maar het is het kleinste onderdeel van een groter probleem. Begrijp dat JavaScript aan de clientzijde waarschijnlijk niet de Slechts type pakket dat u voor altijd in uw projecten wilt opnemen, zelfs als dat op dit moment is - en dat is waar dingen werkelijk beginnen uit elkaar te vallen.

Veel productie-apps gebruiken een combinatie van de volgende tools en pakketten, zo niet allemaal:

• Sass (maakt het schrijven van CSS makkelijker)
• PostCSS (verbetert CSS voor maximale efficiëntie en compatibiliteit)
• Babel (transpileert nieuwer JavaScript om in oudere browsers te draaien)
• TypeScript (voegt typecontrole toe aan JavaScript)
• Hot module herladen door een dev-server die de browser automatisch ververst om uw wijzigingen te tonen
• Extra hulpprogramma's voor codebundeling, minificatie en/of concatenatie
• Automatische beeldcompressie
• Bibliotheken testen
• Linters

Dat klinkt allemaal geweldig - en dat is het ook! - maar merk op dat je nu meerdere afhankelijkheden hebt die niet alleen niet aanwezig zijn in uw scripttags, maar zijn helemaal nergens in uw project verantwoord! Niemand, ook je toekomstige zelf, kan op geen enkele manier enig idee hebben welke tools zijn gebruikt of nodig zijn om dit project te laten draaien.

En zelfs als je op die manier precies zou weten wat het project nodig had, zou je nog steeds zelf al die pakketten moeten zoeken, downloaden en installeren... handmatig. Afhankelijk van het project kan dit gemakkelijk een dagtaak zijn, of langer.

Dit alles betekent dat uw workflow er nu een beetje meer als volgt uitziet:

Hoe handig alle tools hierboven ook zijn, u moet nog steeds: beheer aan hen. Afhankelijkheden zijn ook projecten en ze verzenden updates om bugs te patchen en nieuwe functies te introduceren. Als zodanig is het onrealistisch om simpelweg een scripttag in de HTML te plakken met een link die verwijst naar het pakket op een CDN en het dan goed te noemen. Je moet ervoor zorgen dat alles is geïnstalleerd en goed werkt, niet alleen op jouw machine, maar ook op de machine van elke medewerker.

Pakketbeheerders zijn er om de pakketten - of afhankelijkheden - van een project beheersbaar te maken door te weten wat er is geïnstalleerd, wat er kan worden bijgewerkt en of het ene pakket conflicten met het andere kan veroorzaken. En het mooie van een pakketbeheerder is dat hij dit allemaal rechtstreeks vanaf de opdrachtregel doet, met minimale inspanning.

Veel pakketbeheerders, vooral npm, bieden ook extra functies die nog meer mogelijkheden bieden om de ontwikkeling efficiënter te maken. Maar het beheren van pakketten is de belangrijkste attractie.

Er zijn pakketbeheerders die geen npm zijn

Dit deel is niet super relevant voor npm zelf, maar voor de volledigheid moet ik ook vermelden dat npm niet de Slechts JavaScript-pakketbeheerder. U ziet bijvoorbeeld: Garen waarnaar wordt verwezen in codevoorbeelden. Garen en npm werken vrijwel op dezelfde manier, in de mate dat er met opzet veel interoperabiliteit tussen de twee is ingebouwd.

Sommige mensen geven de voorkeur aan de ene pakketbeheerder boven de andere. Persoonlijk denk ik dat de verschillen tussen npm en Yarn in het begin meer uitgesproken waren, maar de twee lijken nu meer op elkaar dan niet.

Mogelijk ziet u codevoorbeelden (inclusief enkele in CSS-Tricks-artikelen) die naar beide verwijzen yarn en npm samen. Dat is om de lezer te laten weten dat beide benaderingen prima zijn, in plaats van dat ze beide samen moeten worden gebruikt.

De syntaxis voor Yarn en npm verschilt soms, maar als er maar één aanwezig is, is het over het algemeen triviaal om een ​​commando of project van het ene naar het andere te converteren. Functioneel gezien maakt het zelden (of nooit) uit welke je gebruikt, behalve natuurlijk dat iedereen die samen aan hetzelfde project werkt, hetzelfde wil gebruiken om compatibiliteit en consistentie te garanderen.

Hoewel npm en Yarn de overgrote meerderheid vormen van pakketbeheerders die ontwikkelaars gebruiken, er is nog een pakketbeheerder genaamd PnPm dat is effectief npm, maar performanter en efficiënter. De wisselwerking is dat PnPm in sommige gevallen wat meer technische knowhow vereist, dus het is een beetje meer een geavanceerde optie.

Wat maakt npm tot de "standaard" pakketbeheerder?

Nogmaals, ik breng alleen andere pakketbeheerders naar voren om te illustreren dat npm niet de enige pakketbeheerder is die er is, maar over het algemeen is het de standaard.

Wat maakt het de “standaard” onder pakketbeheerders? Andere talen, waaronder Ruby en PHP, hebben al vele jaren pakketbeheerders; JavaScript had echt geen goede voor npm.

npm begon als een onafhankelijk, open source project, maar was overgenomen door Microsoft in 2020. Het bestaat technisch gezien uit twee delen: de eigenlijke pakketbeheerder zelf; en het pakketregister, dat een steeds groter wordende lijst is van bijna twee miljoen pakketten beschikbaar om te installeren.

Je zou npm kunnen zien als de app store voor alles wat je zou willen gebruiken in een front-end of node-gebaseerd project. Zoek wat u zoekt en installeer het via de opdrachtregel op uw systeem. U kunt dat pakket bijwerken wanneer een nieuwe versie wordt uitgebracht, of het geheel verwijderen als het project er niet langer van afhankelijk is.

Een opmerking over npx

Je kan ook zien npx commando's die daar rondzweven. npx is eigenlijk een onderdeel van npm, maar door npx in een commando in plaats van npm , kunt u de code van een pakket uitvoeren zonder blijvend installeren. NPX installeert gewoon wat het nodig heeft, voert het uit en dumpt het.

Dit is handig als u bijvoorbeeld een installatiescript wilt uitvoeren. In plaats van het installatieprogramma te downloaden, harte als u het uitvoert, kunt u met npx het installatieprogramma eenvoudig rechtstreeks uitvoeren, zodat er daarna niets op uw computer achterblijft. Het is als de huisgast die zichzelf opruimt.

Nog een cool voorbeeld: je zou kunnen rennen npx sass (samen met de nodige invoer- en uitvoerargumenten) als u de Sass-bestanden van uw project slechts één keer wilt compileren zonder de moeite te nemen Sass volledig te installeren. Dit is in de meeste gevallen waarschijnlijk niet praktisch, maar als je hier en daar een snelle eenmalige compilatie nodig hebt, zou npx een handige manier zijn om dit te doen, omdat het minder geïnstalleerde pakketten betekent die moeten worden bijgewerkt en onderhouden.

Wat is het volgende

Oké, dus dat is een diepe duik in wat we bedoelen als we iets een pakketbeheerder noemen. In het geval van npm wordt het specifiek gebruikt voor het installeren en beheren van Node-pakketten, tools die helpen bij het toevoegen van functies aan een project, het toevoegen van handige ontwikkelaarsgemakken... of al het bovenstaande!

Vervolgens gaan we onze eerste stap zetten in gebruik npm. En om dat te doen, moeten we het op ons systeem installeren. Dat is de volgende stap in deze complete gids voor npm.

Bron: https://css-tricks.com/what-the-heck-is-a-package-manager/