LimeSoda Blog ☰ Zeige Kategorien

npm – Die eierlegende Wollmilchsau

Der „Node Package Manager“ (npm) ist mittlerweile zum Standard für die Paketverwaltung in der JavaScript-Welt mutiert. Vor einiger Zeit musste man sich noch mit bower herumplagen, mittlerweile gibt es aber jedes wichtige Paket auch per npm und der Abstand zu bower vergrössert sich stetig:

Grafik Modulvergleich npm/bower

Quelle: http://www.modulecounts.com/

Aus der Grafik ist recht eindrucksvoll ersichtlich dass uns npm noch länger begleiten wird, und das ist auch gut so. Es kann jedenfalls nicht schaden sich näher mit dem Tool auseinander zu setzen.

Initialisierung

Grundlage von npm ist eine package.json Datei pro Projekt. Diese beinhaltet unter anderem den Projektnamen, alle Dependencies und Versionen, aber auch sogenannte run scripts. Die package.json wird per npm init im Projekt-Root erstellt. Hier ein einfaches Beispiel:

Dependency Resolution

Pakete besitzen meist Abhängigkeiten, diese müssen natürlich ebenfalls installiert werden. Bei Version 2 wurden diese unter jedem installierten Paket extra installiert. Hier am Beispiel eines Paketes „moduleA“ mit der Abhängigkeit „moduleB“:

Das Problem: Wird ein neues Modul installiert, welches die gleiche Abhängigkeit besitzt, so wird diese mehrfach installiert:

Version 3 von npm löst das Problem, indem Sub-Abhängigkeiten „flat“ installiert werden. Installiert man also „moduleA“ und „moduleC“, so sieht die Ordnerstruktur danach wie folgt aus:

Das kann zwar zu Verwirrung führen, nachdem „moduleB“ nicht in der package.json aufscheint, sorgt aber für weniger Redundanz.

Natürlich kann „moduleC“ eine andere Version von „moduleB“ benötigen als „moduleA“, in diesem Fall fällt npm wieder auf die frühere Verschachtelung zurück:

Das Verhalten wird hier ebenfalls anschaulich erklärt: https://docs.npmjs.com/how-npm-works/npm3

Globale/Lokale Dependencies

Nicht nur Projektabhängigkeiten können per npm installiert werden, sondern auch Command Line Tools wie zum Beispiel gulp oder webpack. Wichtig ist hierbei die globale Installation mit dem Parameter -g. Es können auch gleich mehrere Pakete gleichzeitig installiert werden:

Lokale Dependencies sollten immer mit dem Parameter –save oder –save-dev installiert werden, damit sie gleich in die package.json aufgenommen werden. Ein Unterschied besteht hierbei nur in der Platzierung innerhalb der package.json. Grundsätzlich werden per –save-dev Pakete installiert die zur Entwicklung benötigt werden (Test-Frameworks, Build-Tools, …). Per –save werden Pakete installiert welche zur Laufzeit verwendet werden (jQuery, React, …):

Update von npm-Paketen

Pakete während der Entwicklung aktuell zu halten macht nicht immer Sinn, bei längerer Entwicklungszeit kann es notwendig werden durch ein Dependency-Update den Code umzuschreiben. Es spricht aber ansonsten nichts dagegen, vor allem wenn man brav seine Unit Tests geschrieben hat ;)

Vor dem Update sollte man per npm outdated prüfen, für welche Pakete es neue Versionen gibt:

npm outdatedDamit die Paketversionen in der package.json ebenfalls angepasst werden, sollte npm update –save oder npm update –save-dev verwendet werden.

Run Scripts und Lifecycle Hooks

Es gibt eine Reihe von vordefinierten Lifecycle Hooks, mit denen automatisch Scripte aufgerufen werden können. Eine vollständige Liste befindet sich in der offiziellen Dokumentation: https://docs.npmjs.com/misc/scripts.

Sehr interessant ist aber auch die Möglichkeit eigene Scripte aufzurufen. Der Trend geht aktuell weg von Task Runners wie Grunt oder Gulp zu simplen Node.js-Scripts, welche per npm aufgerufen werden. Im oben angeführten Beispiel einer package.json Datei existieren bereits einige Run Scripts, hiermit können diese aufgerufen werden:

Eigene Pakete publishen

Irgendwie müssen die Pakete natürlich auch programmiert werden, damit sie ein anderer User verwenden kann. Auch das funktioniert mit npm über die Kommandozeile:

Als „restricted“ kann ein Paket nur mit einem kostenpflichtigen npm Account published werden. Die vollständige Dokumentation: https://docs.npmjs.com/cli/publish

Davor muss natürlich ein npm Benutzerkonto angelegt werden, mit welchem man sich vor dem Publishen verbindet:

Nach „leftpadgate“ hat npm verhindert dass einmal veröffentlichte Pakete einfach entfernt werden können, um Abhängigkeiten zu anderen Paketen aufrecht zu erhalten. npm unpublish funktioniert daher nur noch 24 Stunden, danach kann ein Paket nur als „deprecated“ markiert werden: https://docs.npmjs.com/cli/deprecate

Ich hoffe dass ich die eine oder andere unbekannte Funktion näherbringen konnte, npm ist jedenfalls ein geniales Tool und sollte mittlerweile von jedem Frontent-Developer verwendet werden. Dann natürlich auch gleich mit all den coolen Dingen, die sich per npm simpel installieren lassen: Babel, Webpack, React, …

Kommentare

Hinterlasse einen Fingerabdruck für die Ewigkeit: Ein Kommentar bei LimeSoda!

(*) Pflichtfeld

Bewirb dich bei uns!

LimeSoda.
Digitalagentur in Wien.

Bewirb dich jetzt!
Andreas Teufel

Verpasse nicht den nächsten Blog-Post von Andreas!

Jetzt zum LimeSoda-Newsletter anmelden