Wer am Beginn von Node.js steht ist mit dem Umgang von NPM und den gebotenen Möglichkeiten oft nicht vertraut. Gerade mit Hilfe der Datei package.json können zahlreiche Arbeitsschritte massiv vereinfacht (und im Team verallgemeinert) werden. Dieser Beitrag zeigt auf, wie damit immer wiederkehrender Aufwand gespart werden kann.
Node Package Manager (NPM)
Mit Hilfe des Node Package Managers können zusätzliche Node-Module installiert bzw. eigene Module veröffentlicht werden. Das gesamte Spektrum ist nachfolgend zu sehen:
Vorhandene Module finden
Existierende Module können via npmjs.org/ gefunden werden. Eine weitere Möglichkeit besteht durch den Aufruf
npm search [searchkey]
Als Ergebnis werden alle gefundenen Module zurück geliefert:
Neben der Anzeige des Modulnamens werden auch eine Beschreibung, der Autor und entsprechende Keywords (für die Suche) angezeigt.
Module installieren
Ist der Name eines Modules bekannt kann dies mit der Option install installiert werden:
Hier ist schön zu sehen, dass auch Abhängigkeiten installiert werden.
Installierte Module auflisten
Die Option list ermöglicht zudem das Auflisten von installierten Modulen und Abhängigkeiten im aktuellen Verzeichnis:
package.json
Wer nun selbst Module entwickelt (egal ob für den internen, oder den öffentlichen Gebrauch) muss sich eine Datei namens package.json pro Module anlegen. Dieses enthält wichtige Metadaten zu dem Modul. Sehen wir uns eine derartige Datei näher an:
{
"name": "ideamark",
"description": "A simple nodejs document store for ideas, concepts, documentation supporting markdown",
"author": "Norbert Eder <wpfnerd+nodejs@gmail.com>",
"homepage": "github.com/devtyr/ideamark",
"bugs": "github.com/devtyr/ideamark/issues",
"version": "0.3.0",
"license": "MIT",
"keywords": [
"blog",
"markdown",
"live-update",
"documents",
"ideas",
"documentation",
"specification"
],
"repository": {
"type": "git",
"url": "git://github.com/devtyr/ideamark.git"
},
"dependencies": {
"mime": ">=1.2.4",
"connect": ">=2.0.0",
"marked": ">=0.1.2",
"optimist": ">=0.3.0",
"qs": ">=0.4.0",
"winston": ">=0.5.9"
},
"scripts": {
"start": "node server.js -s"
},
"engines": {
"node": ">= 0.6.0"
},
"devDependencies": {}
}
Neben Angaben zum Namen, Beschreibung, Autor, Version, Lizenz und Keywords des Modules befinden sich einige sehr hilfreiche Definitionen in dieser Datei:
dependencies
Diese definieren die Abhängigkeiten des Modules, die via NPM möglich sind und zusammen mit dem Modul installiert werden sollen. Für die Angabe der abhängige Version stehen mehrere Varianten zur Verfügung:
- version: Muss exakt version entsprechen
- =version: Entspricht version
- >version: Größer als die definierte Version
- >=version: Größer bzw. gleich der definierten Version
- <version: Kleiner als die definierte Version
- <=version: Kleiner bzw. gleich der definierten Version
Eine weitere Möglichkeit die mögliche Version einzugrenzen wird durch Tilde Version Ranges ermöglicht. Hierzu wird ~ der Version vorangesetzt. Die tatsächliche Version muss mindestens gleich der der definierten sein, aber kleiner der nächsten Hauptrevision. Beispiel:
- "~1.2.3" = ">=1.2.3 <1.3.0"
- "~1.2" = ">=1.2.0 <2.0.0"
- "~1" = ">=1.0.0 <2.0.0"
Zusätzlich kann via x ein Platzhalter definiert werden. Beispiel:
- "1.2.x" = ">=1.2.0 <1.3.0"
Info: Als Abhängigkeit kann auch ein Verweis zu einem Repository angegeben werden.
devDependencies
Hier werden die referenzierten Module definiert, die für die Entwicklung an diesem Modul notwendig sind. Beispielsweise betrifft dies Abhängigkeiten zu Testing-Modulen, die für die Entwicklung notwendig, für die Verwendung jedoch unerheblich sind. Standardmäßig werden alle Abhängigkeiten installiert. Um sicher zu gehen, dass die für die Entwicklung notwendigen Abhängigkeiten nicht installiert werden, sollte das Modul mit folgendem Aufruf installiert werden:
npm install –production
Dieser Aufruf muss im Modul-Root erfolgen. Die Basis-Installation eines Modules via npm install modulname installiert die devDependencies nicht mit. Es ist sehr empfehlenswert für jede zusätzliche Abhängigkeit genau zu prüfen, für welches Umfeld sie notwendig ist und entsprechend zu konfigurieren.
scripts
Hier können für unterschiedlichste Fälle Scripts angegeben werden. Unterstützt werden folgende Einträge:
- preinstall: Werden vor der Installation ausgeführt
- install, postintall: Werden nach der Installation ausgeführt
- preuninstall, uninstall: Werden vor der Deinstallation ausgeführt
- postuninstall: Werden nach der Deinstallation ausgeführt
- preupdate: Laufen vor der Aktualisierung
- update, postupdate: Laufen nach der Aktualisierung
- prepublish: Laufen vor der Veröffentlichung des Paketes
- publish, postpublish: Laufen nach der Veröffentlichung des Paketes
- pretest, test, posttest: Werden durch den Aufruf von npm test ausgeführt
- prestop, stop, poststop: Werden durch den Aufruf von npm stop ausgeführt
- prestart, start, poststart: Werden durch den Aufruf von npm start ausgeführt
- prerestart, restart, postrestart: Werden durch den Aufruf von npm restart ausgeführt. Wird kein restart-Script angegeben, wird zuerst stop und dann start durchlaufen.
Gerade wer auf unterschiedlichen Rechnern oder im Team entwickelt, sollte davon unbedingt Gebrauch machen, da darüber sehr viel Aufwand eingespart werden kann. Einzelne Scripts können mit dem Befehl
npm run-script test
ausgeführt werden. In diesem Fall würde das unter test definierte Script ausgeführt werden. Die Verwendung der anderen Möglichkeiten funktioniert analog dazu.
main
In der oben angeführten package.json wird ein Eintrag nicht benötigt: main. Diese Einstellung definiert den Einstiegspunkt, wenn das Modul über require eingebunden wird.
Um eine vollständige Liste der unterstützten Attribute durch NPM zu erhalten, ist folgender Aufruf durchzuführen:
npm help json
Veröffentlichen von Modulen
Wer nun eigene Module veröffentlichen möchte, registriert sich auf npmjs.org einen Benutzer. Dieser muss via
npm add-user
der lokalen Registrierung hinzugefügt werden. Danach kann das Modul (package.json muss vorhanden sein) via
npm publish <Verzeichnis>
veröffentlicht werden. Wahlweise kann auch eine Url oder ein Tar-Archiv verwendet werden. Sollte es Probleme beim Aktualisieren geben (Version existiert bereits) kann ein Überschreiben via –force durchgeführt werden.
Zusätzliche Informationen
Weitere hilfreiche Informationen zu NPM können über die NPM-Hilfe bezogen werden.