Articles

Skripte

On Dezember 17, 2021 by
Inhaltsverzeichnis

Beschreibung

Die "scripts"Eigenschaft Ihrer package.jsonDatei unterstützt eine Reihe von eingebauten Skripten und deren voreingestellte Lebenszyklusereignisse sowie beliebige Skripte. Diese können alle durch Ausführen von npm run-script <stage> oder kurz npm run <stage> ausgeführt werden. Vor- und Nachbefehle mit übereinstimmenden Namen werden ebenfalls ausgeführt (z. B. premyscript, myscript, postmyscript). Skripte aus Abhängigkeiten können mit npm explore <pkg> -- npm run <stage> ausgeführt werden.

Pre & Post Skripte

Um „pre“ oder „post“ Skripte für beliebige Skripte zu erstellen, die im "scripts" Abschnitt des package.json definiert sind, erstellen Sie einfach ein weiteres Skript mit einem passenden Namen und fügen Sie „pre“ oder „post“ an den Anfang von ihnen.

 { 
 "Skripte": { 
 "precompress": "{{ wird VOR dem `compress`-Skript ausgeführt }}", 
 "compress": "{{ Befehl zum Komprimieren von Dateien ausführen }}", 
 "postcompress": "{{ führt NACH dem Skript `compress` aus }}" 
 } 
 }

Life Cycle Scripts

Es gibt einige spezielle Life Cycle Scripts, die nur in bestimmten Situationen ausgeführt werden. Diese Skripte werden zusätzlich zu den Skripten „Pre“ und „Post“ ausgeführt.

  • prepare, prepublish, prepublishOnly, prepack, postpack

prepare (seit [email protected])

  • Läuft BEVOR das Paket gepackt wird
  • Läuft BEVOR das Paket veröffentlicht wird
  • Läuft auf lokalem npm install ohne Argumente
  • Läuft NACH prepublish, aber VOR prepublishOnly
  • HINWEIS: Wenn ein Paket, das über Git installiert wird, ein prepare-Skript enthält, werden dessen dependencies und devDependencies installiert und das Prepare-Skript wird ausgeführt, bevor das Paket gepackt und installiert wird.

prepublish (DEPRECATED)

  • Gleich wie prepare

prepublishOnly

  • Läuft BEVOR das Paket vorbereitet und gepackt wird, NUR auf npm publish.

prepack

  • Läuft BEVOR ein Tarball gepackt wird (auf „npm pack„, „npm publish“ und bei der Installation von Git-Abhängigkeiten).
  • Hinweis: „npm run pack“ ist NICHT dasselbe wie „npm pack„. „npm run pack“ ist ein beliebiger benutzerdefinierter Skriptname, während „npm pack“ ein CLI-definierter Befehl ist.

postpack

  • Läuft, NACHDEM der Tarball erzeugt und an seinen endgültigen Bestimmungsort verschoben wurde.

Prepare and Prepublish

Hinweis: prepublish

Seit [email protected] hat das npm CLI das Skript prepublish sowohl für npm publish als auch für npm install ausgeführt, weil es ein bequemer Weg ist, ein Paket für die Verwendung vorzubereiten (einige häufige Anwendungsfälle werden im folgenden Abschnitt beschrieben). Es hat sich in der Praxis aber auch als sehr verwirrend erwiesen. Ab [email protected] wurde ein neues Ereignis eingeführt, prepare, das dieses bestehende Verhalten beibehält. Ein neues Ereignis, prepublishOnly, wurde als Übergangsstrategie hinzugefügt, um es den Benutzern zu ermöglichen, das verwirrende Verhalten der bestehenden npm-Versionen zu vermeiden und nur npm publish auszuführen (zum Beispiel, um die Tests ein letztes Mal auszuführen, um sicherzustellen, dass sie in gutem Zustand sind).

Siehe https://github.com/npm/npm/issues/10074 für eine viel längere Begründung, mit weiterführender Lektüre, für diese Änderung.

Verwendungsfälle

Wenn Sie Operationen an Ihrem Paket durchführen müssen, bevor es verwendet wird, in einer Art und Weise, die nicht vom Betriebssystem oder der Architektur des Zielsystems abhängig ist, verwenden Sie ein prepublishSkript. Dazu gehören Aufgaben wie:

  • Kompilieren von CoffeeScript-Quellcode in JavaScript.
  • Erstellen von verkleinerten Versionen von JavaScript-Quellcode.
  • Abrufen von Remote-Ressourcen, die Ihr Paket verwenden wird.

Der Vorteil, diese Dinge zur prepublish Zeit zu tun, ist, dass sie einmal an einer einzigen Stelle durchgeführt werden können, was die Komplexität und Variabilität reduziert. Außerdem bedeutet dies, dass:

  • Sie sich auf coffee-script als devDependency verlassen können und Ihre Benutzer es nicht installiert haben müssen.
  • Sie müssen keine Minifier in Ihr Paket aufnehmen, was die Größe für Ihre Benutzer reduziert.
  • Sie müssen sich nicht darauf verlassen, dass Ihre Benutzer curl oder wget oder andere Systemwerkzeuge auf den Zielmaschinen haben.

Life Cycle Operation Order

npm publish

  • prepublishOnly
  • prepare
  • prepublish
  • publish
  • postpublish

npm pack

  • prepack
  • postpack

npm install

  • preinstall
  • install
  • postinstall

Auch auslösend

  • prepublish (wenn auf lokaler Ebene)
  • prepare (wenn auf lokaler Ebene)

npm start

npm run start hat eine npm start Kurzform.

  • prestart
  • start
  • poststart

Standardwerte

npm gibt einige Skriptwerte basierend auf dem Paketinhalt vor.

  • "start": "node server.js":

    Wenn es eine server.js Datei in der Wurzel deines Pakets gibt, dann wird npm den start Befehl auf node server.js vorgeben.

  • "install": "node-gyp rebuild":

    Wenn es eine binding.gyp Datei in der Wurzel deines Pakets gibt und du keine eigenen install oder preinstall Skripte definiert hast, dann wird npm den install Befehl standardmäßig mit node-gyp kompilieren.

User

Wenn npm mit Root-Rechten aufgerufen wurde, dann ändert es die uid auf das Benutzerkonto oder die uid, die in der user-Konfiguration angegeben ist, die standardmäßig nobody ist. Setzen Sie das unsafe-perm Flag, um Skripte mitroot-Rechten auszuführen.

Environment

Paket-Skripte werden in einer Umgebung ausgeführt, in der viele Informationen über das Setup von npm und den aktuellen Status des Prozesses zur Verfügung gestellt werden.

path

Wenn Sie von Modulen abhängen, die ausführbare Skripte definieren, wie z.B. Testsuiten, dann werden diese ausführbaren Dateien zum PATH hinzugefügt, um die Skripte auszuführen. Also, wenn deine package.json folgendes hat:

 { 
 "name" : "foo", 
 "dependencies" : { 
 "bar" : "0.1.x" 
 }, 
 "scripts": { 
 "start" : "bar ./test" 
 } 
 }

dann könnten Sie npm start ausführen, um das bar-Skript auszuführen, das in das node_modules/.bin-Verzeichnis auf npm install exportiert wird.

package.json vars

Die package.json-Felder werden an das npm_package_-Präfix angehängt. Wenn Sie also zum Beispiel {"name":"foo", "version":"1.2.5"} in Ihrer package.json-Datei haben, dann würde in Ihren package-Skripten dienpm_package_name Umgebungsvariable auf „foo“ und dienpm_package_version auf „1.2.5“ gesetzt sein. Sie können auf diese Variablen in Ihrem Code mit process.env.npm_package_name undprocess.env.npm_package_version zugreifen, und so weiter für andere Felder.

Konfiguration

Konfigurationsparameter werden mit dem Präfixnpm_config_ in die Umgebung gestellt. Zum Beispiel können Sie die effektive rootKonfiguration sehen, indem Sie die npm_config_root-Umgebungsvariable überprüfen.

Spezial: package.json „config“-Objekt

Die package.json „config“-Schlüssel werden in der Umgebung überschrieben, wenn es einen config-Parameter von <name>:<key> gibt. Zum Beispiel, wenn die package.json folgendes hat:

 { 
 "name" : "foo", 
 "config" : { 
 "port" : "8080" 
 }, 
 "scripts" : { 
 "start" : "node server.js" 
 } 
 }

und die server.js ist dies:

 http.createServer(...).listen(process.env.npm_package_config_port)

dann könnte der Benutzer das Verhalten ändern, indem er folgendes tut:

 npm config set foo:port 80

current lifecycle event

Schließlich wird die npm_lifecycle_event Umgebungsvariable auf die jeweilige Phase des Zyklus gesetzt. Man könnte also ein einziges Skript für verschiedene Teile des Prozesses verwenden, das je nachdem, was gerade passiert, umschaltet.

Objekte werden nach diesem Format geglättet, wenn Sie also{"scripts":{"install":"foo.js"}} in Ihrem package.json haben, dann würden Sie dies im Skript sehen:

 process.env.npm_package_scripts_install === "foo.js"

Beispiele

Wenn Ihre package.json zum Beispiel dies enthält:

 { 
 "scripts" : { 
 "install" : "scripts/install.js", 
 "postinstall" : "scripts/install.js", 
 "uninstall" : "scripts/uninstall.js" 
 } 
 }

dann wird scripts/install.js für die Installations- und Post-Installationsphasen des Lebenszyklus aufgerufen und scripts/uninstall.js wird aufgerufen, wenn das Paket deinstalliert wird. Da scripts/install.js für zwei verschiedene Phasen läuft, wäre es in diesem Fall ratsam, sich die Umgebungsvariable npm_lifecycle_event anzusehen.

Wenn Sie einen make-Befehl ausführen wollen, können Sie das tun. Das funktioniert ganz gut:

 { 
 "scripts" : { 
 "preinstall" : "./configure", 
 "install" : "make && make install", 
 "test" : "make test" 
 } 
 }

Beenden

Skripte werden ausgeführt, indem die Zeile als Skriptargument an sh übergeben wird.

Wenn das Skript mit einem anderen Code als 0 beendet wird, wird der Prozess abgebrochen.

Beachte, dass diese Skriptdateien keine Nodejs- oder sogar Javascript-Programme sein müssen. Sie müssen nur eine Art von ausführbarer Datei sein.

Hook Scripts

Wenn Sie ein bestimmtes Skript zu einem bestimmten Lebenszyklus-Ereignis für ALLE Pakete ausführen wollen, dann können Sie ein Hook-Skript verwenden.

Platzieren Sie eine ausführbare Datei bei node_modules/.hooks/{eventname}, und sie wird für alle Pakete ausgeführt, wenn sie diesen Punkt im Lebenszyklus der Pakete für alle Pakete, die in diesem Stamm installiert sind, durchlaufen.

Hook-Skripte werden genauso ausgeführt wie package.json-Skripte, d.h. sie befinden sich in einem separaten Kindprozess mit der oben beschriebenen Umgebung.

Best Practices

  • Beenden Sie den Vorgang nicht mit einem Fehlercode ungleich Null, es sei denn, Sie meinen es wirklich ernst.Außer bei Deinstallationsskripten führt dies dazu, dass die npm-Aktion fehlschlägt und möglicherweise zurückgesetzt wird. Wenn der Fehler geringfügig ist oder nur einige optionale Funktionen verhindert, dann ist es besser, nur eine Warnung auszugeben und die Aktion erfolgreich zu beenden.
  • Versuchen Sie, keine Skripte zu verwenden, um das zu tun, was npm für Sie tun kann. Lesen Sie sich durchpackage.json, um all die Dinge zu sehen, die Sie angeben und aktivieren können, indem Sie einfach Ihr Paket entsprechend beschreiben. Im Allgemeinen wird dies zu einem robusteren und konsistenteren Zustand führen.
  • Inspektiere die Umgebung, um zu bestimmen, wo du Dinge ablegen willst. Wenn zum Beispiel die Umgebungsvariable npm_config_binroot auf /home/user/bin gesetzt ist, dann versuchen Sie nicht, ausführbare Dateien in /usr/local/bin zu installieren. Der Benutzer hat es wahrscheinlich aus einem bestimmten Grund so eingerichtet.
  • Setzen Sie Ihren Skriptbefehlen kein „sudo“ voran. Wenn aus irgendeinem Grund Root-Berechtigungen erforderlich sind, wird es mit diesem Fehler fehlschlagen, und der Benutzer wird den fraglichen npm-Befehl sudo ausführen.
  • Verwenden Sie nicht install. Verwenden Sie eine .gyp Datei für die Kompilierung und prepublish für alles andere. Sie sollten fast nie explizit ein Reinstall- oder Installationsskript einstellen müssen. Wenn Sie dies tun, überlegen Sie bitte, ob es eine andere Möglichkeit gibt. Die einzige gültige Verwendung von install oder preinstallSkripten ist für die Kompilierung, die auf der Zielarchitektur durchgeführt werden muss.

Siehe auch

  • npm run-script
  • package.json
  • npm developers
  • npm install

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.