Die umfassendste package.json-Analyse

1. Übersicht

Seit wir mit der Arbeit am Front-End begonnen haben, befindet sich im Stammverzeichnis jedes Projekts im Allgemeinen eine Datei package.json. Diese Datei definiert die verschiedenen für das aktuelle Projekt erforderlichen Module sowie die Konfigurationsinformationen des Projekts (wie Name, Version, Lizenz usw.).

Wenn Sie den Befehl npm install ausführen, werden die erforderlichen Module automatisch entsprechend der Konfiguration in der Datei package.json heruntergeladen, d. h. der für das Konfigurationsprojekt erforderlichen Ausführungs- und Entwicklungsumgebung.

Die folgende Datei enthält beispielsweise nur einen einfachen Projektnamen und eine Versionsnummer.

{
  "Name" : "Yindong",
  "version" : "1.0.0",
}

Die Datei package.json ist ein JSON-Objekt, wie Sie an der Endung .json erkennen können. Jedes Mitglied des Objekts ist eine Einstellung für das aktuelle Projekt. Beispielsweise ist „Name“ der Projektname und „Version“ die Versionsnummer.

Natürlich kümmern sich viele Leute nicht wirklich um die package.json-Konfiguration, sie verwenden eher Abhängigkeiten oder devDependencies-Konfigurationen.

Unten finden Sie eine ausführlichere package.json-Datei, in der die Bedeutung der einzelnen Felder im Detail erläutert wird.

{
    "Name": "Yindong",
    "Version": "0.0.1",
    "Beschreibung": "Antd-Thema",
    "Schlüsselwörter":["node.js","antd", "Thema"],
    "Homepage": "https://zhiqianduan.com",
    "bugs":{"url":"http://Pfad/zum/Bug","email":"[email protected]"},
    "Lizenz": "ISC",
    "Autor": "yindong",
    "Mitwirkende":[{"Name":"yindong","E-Mail":"[email protected]"}],
    "Dateien": "",
    "Haupt": "./dist/default.js",
    "bin": "",
    "Mann": "",
    "Verzeichnisse": "",
    "Repository": {
  "Typ": "git",
  "url": "https://Pfad/zur/URL"
 },
    "Skripte": {
      "Start": "webpack serve --config webpack.config.dev.js --progress"
    },
    "Konfiguration": { "Port" : "8080" },
    "Abhängigkeiten": {},
    "devAbhängigkeiten": {
        "@babel/core": "^7.14.3",
        "@babel/preset-env": "^7.14.4",
        "@babel/preset-react": "^7.13.13",
        "babel-loader": "^8.2.2",
        "babel-plugin-import": "^1.13.3",
        "glob": "^7.1.7",
        "weniger": "^3.9.0",
        "less-loader": "^9.0.0",
        "Stillader": "^2.0.0",
        "webpack": "^5.38.1",
        "webpack-cli": "^4.7.0",
        "webpack-dev-server": "^3.11.2"
    },
    "Peer-Abhängigkeiten": {
        "Tee": "2.x"
    },
    "gebündelte Abhängigkeiten": [
        „gerendert“, „Super-Streams“
    ],
    "Engines": {"Knoten": "0.10.x"},
   "os" : [ "win32", "darwin", "linux" ],
    "CPU": ["x64", "ia32"],
    "privat": falsch,
    "Konfiguration veröffentlichen": {}
  }

2. Namensfeld

Die wichtigsten Felder in der Datei package.json sind Name und Version, die erforderlich sind. Name und Version bilden zusammen eine Kennung, die als völlig eindeutig gilt. Änderungen an Paketen sollten zusammen mit Änderungen an Versionen vorgenommen werden.
Der Name muss höchstens 214 Zeichen lang sein, darf nicht mit . oder _ beginnen und darf keine Großbuchstaben enthalten. Da der Name letztendlich Teil der URL wird, darf er keine nicht URL-sicheren Zeichen enthalten.
npm empfiehlt offiziell, nicht denselben Namen wie ein Kernknotenmodul zu verwenden. Fügen Sie dem Namen weder „js“ noch „node“ hinzu. Bei Bedarf können Sie Engines verwenden, um die Betriebsumgebung festzulegen.
Der Name wird als Argument an require übergeben und sollte daher kurz, aber einigermaßen aussagekräftig sein.

3. Versionsfeld

Das allgemeine Versionsformat ist xxx und diese Regel muss befolgt werden.
Die wichtigsten Felder in der Datei package.json sind Name und Version, die erforderlich sind. Name und Version bilden zusammen eine Kennung, die als völlig eindeutig gilt. Bei jeder neuen Version kann diese nicht mit der bestehenden identisch sein.

4. Beschreibungsfeld

Beschreibung ist eine Zeichenfolge, die zum Schreiben von Beschreibungsinformationen verwendet wird. Dies hilft den Leuten, Ihr Modul zu finden, wenn sie im npm-Repository suchen.

5. Schlüsselwortfeld

Schlüsselwörter sind ein Array von Zeichenfolgen, das den Benutzern bei der Suche im NPM-Repository dabei hilft, Ihr Modul zu finden.

6. Homepage-Feld

Homepage Die Homepage-Adresse des Projekts.

7. Fehlerfeld

Bugs wird verwendet, um Projektprobleme über die Problemadresse oder eine E-Mail-Adresse zu melden.

"Fehler": { 
  "URL": "https://github.com/owner/project/issues",
  "E-Mail": "[email protected]"
}

8. Lizenzfeld

Die Lizenz ist die Vereinbarung des aktuellen Projekts, die den Benutzern mitteilt, welche Rechte sie zur Verwendung Ihres Moduls haben und welche Einschränkungen bei der Verwendung des Moduls bestehen.
"Lizenz" : "BSD-3-Klausel"

9. Autorenfeld Mitwirkendenfeld

„Autor“ ist eine bestimmte Person, und „Mitwirkende“ bezieht sich auf eine Gruppe von Personen, die alle Mitwirkende am aktuellen Projekt sind. Gleichzeitig ist jeder ein Objekt. Verfügt über ein Namensfeld und optionale URL- und E-Mail-Felder.

"Autor": {
  "Name" : "Yindong",
  "E-Mail": "[email protected]",
  "URL": "https://zhiqianduan.com/"
}

Kann auch als Zeichenfolge geschrieben werden

"Autor": "yindong [email protected] (https://zhiqianduan.com/)"

10. Dateifeld

Der Wert des Dateiattributs ist ein Array, das den Dateinamen oder den Ordnernamen unter dem Modul enthält. Wenn es sich um einen Ordnernamen handelt, werden auch alle Dateien im Ordner eingeschlossen (es sei denn, die Datei ist durch andere Konfigurationen ausgeschlossen).
Sie können eine .npmignore-Datei im Stammverzeichnis des Moduls erstellen. Die in diese Datei geschriebenen Dateien werden ausgeschlossen, auch wenn sie im Dateiattribut geschrieben sind. Die Schreibmethode dieser Datei ähnelt der von .gitignore.

11. Hauptfeld

Das Hauptfeld gibt die zu ladende Eintragsdatei an und diese Datei wird geladen, wenn require importiert wird. Der Standardwert dieses Felds ist index.js im Stammverzeichnis des Moduls.

12. Bin-Feld

Das Bin-Element wird verwendet, um den Speicherort der ausführbaren Datei anzugeben, die jedem internen Befehl entspricht. Wenn Sie ein Knotentool schreiben, werden Sie auf jeden Fall das Bin-Feld verwenden.
Wenn wir ein CLI-Tool schreiben, müssen wir den Ausführungsbefehl des Tools angeben. Beispielsweise lautet der Ausführungsbefehl des häufig verwendeten Webpack-Moduls „webpack“.

"bin": {
  "webpack": "bin/index.js",
}

Wenn wir den Webpack-Befehl ausführen, wird der Code in der Datei bin/index.js ausgeführt.
Das Modul wird als Abhängigkeit installiert, wenn die Bin-Option vorhanden ist. Generieren Sie die entsprechenden Dateien in node_modules/.bin/.
Npm sucht nach dieser Datei und erstellt einen symbolischen Link im Verzeichnis node_modules/.bin/. Da das Verzeichnis node_modules/.bin/ zur Laufzeit zur PATH-Variable des Systems hinzugefügt wird, können Sie diese Skripte beim Ausführen von npm direkt über Befehle ohne Pfad aufrufen.
Alle Befehle im Verzeichnis node_modules/.bin/ können im Format npm run [Befehl] ausgeführt werden. Geben Sie in der Befehlszeile „npm run“ ein und drücken Sie dann die Tabulatortaste, um alle verfügbaren Befehle anzuzeigen.

13. Mannfeld

„man“ wird verwendet, um den Speicherort des Man-Dokuments für das aktuelle Modul anzugeben.

"Mann" :[ "./doc/calc.1" ]

14. Verzeichnisfeld

Verzeichnisse erstellen einige Methoden zum Beschreiben der Struktur des Moduls und teilen dem Benutzer mit, wo sich jedes Verzeichnis befindet.

15. Repository-Feld

Geben Sie eine Code-Repository-Adresse an. Dies ist hilfreich für Personen, die Code zu Ihrem Projekt beitragen möchten.

"Repository" : {
  "Typ": "git", 
  "URL": "https://github.com/npm/npm.git"
}

16. Skriptfeld

scripts gibt die npm-Befehlszeilenabkürzung zum Ausführen von Skriptbefehlen an. Beispielsweise gibt start den Befehl an, der beim Ausführen von npm run start ausgeführt werden soll.

"Skripte": {
  "Start": "Knoten ./start.js"
}

Über das Feld „Skripte“ lassen sich Shell-Befehle schnell ausführen, die als Alias ​​verstanden werden können.
Skripte können in node_modules installierte Module direkt verwenden, was sich von der direkten Ausführung mit dem Befehl npx unterscheidet.

"Skripte": {
  "Build": "Webpack"
}

// npm-Build ausführen
// npx webpack

17. Konfigurationsfeld

Das Konfigurationsfeld wird verwendet, um der Befehlszeile Umgebungsvariablen hinzuzufügen.

{
  "Name" : "Yindong",
  "Konfiguration" : { "Port" : "8080" },
  "Skripte" : { "Start" : "Knotenserver.js" }
}

Anschließend können Sie im Skript server.js auf den Wert des Konfigurationsfelds verweisen.

Konsole.log(Prozess.Umgebung.npm_package_config_port); // 8080

Benutzer können diesen Wert über den NPM-Konfigurationssatz ändern.

npm-Konfigurationssatz Yindong: Port 8000

18. Abhängigkeitsfeld, devDependencies-Feld

Das Feld „dependencies“ gibt die Module an, von denen die Ausführung des Projekts abhängt, und „devDependencies“ gibt die für die Projektentwicklung erforderlichen Module an.

Ihr Wert ist ein Objekt. Jedes Mitglied dieses Objekts besteht aus einem Modulnamen und der entsprechenden Versionsanforderung, die das abhängige Modul und seinen Versionsbereich angibt.

Verwenden Sie beim Installieren von Abhängigkeiten den Parameter --save, um das Modul in die Eigenschaft „dependencies“ zu schreiben, und --save-dev, um das Modul in die Eigenschaft „devDependencies“ zu schreiben.

"devAbhängigkeiten": {
        "webpack": "^5.38.1",
}

Jedes Element im Objekt wird durch ein Schlüssel-Wert-Paar dargestellt, mit dem Modulnamen davor und der Versionsnummer des entsprechenden Moduls dahinter. Die Versionsnummer folgt dem Format „Hauptversion.Nebenversion.Kleine Version“.

Versionshinweise

• Feste Version: Beispielsweise 5.38.1, bei der Installation wird nur die angegebene Version installiert.
• Tilde: Beispielsweise bedeutet ~5.38.1, dass die neueste Version von 5.38.x (nicht niedriger als 5.38.1) installiert werden soll, jedoch nicht 5.39.x. Das heißt, die Haupt- und Nebenversionsnummern werden während der Installation nicht geändert.
• Nummer einfügen: Beispielsweise bedeutet „5.38.1“, dass die neueste Version 5.xx (nicht niedriger als 5.38.1) installiert werden soll, jedoch nicht 6.xx. Das heißt, die Hauptversionsnummer wird während der Installation nicht geändert. Es ist zu beachten, dass sich das Caret-Zeichen genauso verhält wie die Tilde, wenn die Hauptversionsnummer 0 ist. Dies liegt daran, dass es sich um ein Entwicklungsstadium handelt und selbst geringfügige Änderungen der Versionsnummer zu Programminkompatibilitäten führen können.
• latest: Installieren Sie die neueste Version.

19. peerDependencies-Feld

Wenn wir ein Modul entwickeln, treten Probleme auf, wenn das aktuelle Modul und das abhängige Modul beide von einem Drittanbietermodul abhängen und von zwei inkompatiblen Versionen abhängen.

Beispielsweise hängt Ihr Projekt von Version 1.0 von Modul A und Modul B ab und Modul A selbst hängt von Version 2.0 von Modul B ab.
In den meisten Fällen stellt dies kein Problem dar und beide Versionen von Modul B können nebeneinander bestehen und gleichzeitig ausgeführt werden. Es entsteht jedoch ein Problem, wenn diese Abhängigkeit dem Benutzer offengelegt wird.

Das typischste Szenario ist ein Plug-in. Beispielsweise ist Modul A ein Plug-in von Modul B. Das vom Benutzer installierte B-Modul hat die Version 1.0, das A-Plugin kann jedoch nur mit der Version 2.0 des B-Moduls verwendet werden. Wenn der Benutzer zu diesem Zeitpunkt eine Instanz der Version 1.0 von B an A übergibt, treten Probleme auf. Daher ist ein Mechanismus erforderlich, der Benutzer bei der Installation der Vorlage daran erinnert, dass B ein 2.0-Modul sein muss, wenn A und B zusammen installiert werden.

Das Feld „peerDependencies“ wird für das Plug-In verwendet, um die Version des Haupttools anzugeben, die es benötigt. Sie können es über das Feld peerDependencies einschränken. Die Verwendung des myless-Moduls muss von der Version 3.9.x des less-Moduls abhängen.

{
  "Name": "myless",
  "Peer-Abhängigkeiten": {
    "weniger": "3.9.x"
  }
}

Beachten Sie, dass ab npm Version 3.0 PeerDependencies nicht mehr standardmäßig installiert werden. Es wird während der Initialisierung nicht standardmäßig angezeigt.

20. Feld „bundledDependencies“

„bundledDependencies“ gibt die Module an, die beim Veröffentlichen zusammen gebündelt werden.

21. optionalDependencies-Feld

Wenn ein Abhängigkeitsmodul verwendet werden kann und Sie möchten, dass npm auch dann weiter ausgeführt wird, wenn das Modul nicht gefunden wird oder nicht abgerufen werden kann, können Sie diese Modulabhängigkeit in die Konfiguration „optionalDependencies“ einfügen. Diese Konfiguration wird auf die gleiche Weise wie Abhängigkeiten geschrieben, mit der Ausnahme, dass ein Fehler bei der Modulinstallation hier nicht dazu führt, dass die npm-Installation fehlschlägt.

22. Motorenfeld

Das Feld „Engines“ gibt die Plattform an, auf der das Modul ausgeführt wird, beispielsweise eine Version von Node oder npm oder ein Browser.

{ "engines" : { "node" : ">=0.10.3 <0.12", "npm" : "~1.0.20" } }

23. os-Feld

Sie können angeben, auf welchen Betriebssystemen Ihr Modul nur ausgeführt werden kann

"Betriebssystem" : [ "darwin", "linux", "win32" ]

24. CPU-Feld

Beschränken Sie die Ausführung des Moduls auf eine bestimmte CPU-Architektur

"Zentrale" : [ "x64", "ia32" ]

25. Private Felder

Wenn diese Eigenschaft auf true gesetzt ist, lehnt npm die Veröffentlichung ab. Dies soll verhindern, dass ein privates Modul versehentlich veröffentlicht wird.

"privat": wahr

26. publishConfig-Feld

Diese Konfiguration wird wirksam, wenn das Modul veröffentlicht wird, und wird verwendet, um einen Satz von Werten festzulegen, die für die Veröffentlichung verwendet werden. Wenn Sie nicht möchten, dass das Modul standardmäßig als das neueste markiert oder standardmäßig in einem öffentlichen Repository veröffentlicht wird, können Sie hier das Tag oder die Repository-Adresse konfigurieren.

Normalerweise wird publishConfig mit private verwendet, wenn das Modul nur in einem bestimmten npm-Repository veröffentlicht werden soll, beispielsweise einem internen Repository.

"privat": wahr,
"Konfiguration veröffentlichen": {
  "tag": "1.0.0",
  "Registrierung": "https://registry.npmjs.org/",
  "Zugriff": "öffentlich"
}

27. preferGlobal-Feld

Der Wert von „preferGlobal“ ist ein Boolescher Wert, der angibt, ob eine Warnung angezeigt werden soll, wenn der Benutzer das Modul nicht als globales Modul installiert (d. h. ohne den Parameter „–global“), und dass dadurch darauf hingewiesen wird, dass das Modul als globales Modul installiert werden soll.

"preferGlobal": falsch

28. Browserfeld

Browser gibt die vom Browser verwendete Version der Vorlage an. Browser-Paketierungstools wie Browserify können Ihnen dabei helfen, herauszufinden, welche Datei Sie paketieren müssen.

"Browser": {
  "tipso": "./node_modules/tipso/src/tipso.js"
},

Verweise

[1] npm-Paket.json
[2] JavaScript Standardreferenz-Tutorial

Dies ist das Ende dieses Artikels über die umfassendste Analyse von package.json. Weitere relevante Inhalte zur Analyse von package.json finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!