Front-End-JavaScript-Housekeeper-Paket.json

Vorwort:

Werfen wir heute einen Blick auf die Konfigurationen der Front-End-Datei package.json . Ein umfassendes Verständnis dieser Konfigurationen hilft uns, die Entwicklungseffizienz zu verbessern und unsere Projekte zu standardisieren. Der Artikel enthält viel Inhalt. Es wird daher empfohlen, ihn zunächst zum Lernen zu speichern!

In jedem Front-End-Projekt gibt es eine Datei package.json , die die Konfigurationsdatei des Projekts ist. Zu den üblichen Konfigurationen gehören das Konfigurieren des Projektstarts, das Verpacken von Befehlen, das Deklarieren abhängiger Pakete usw. Die Datei package.json ist ein JSON-Objekt, dessen jedes Mitglied eine Einstellung für das aktuelle Projekt ist. Welche Konfigurationen von package.json sind als Verwalter des Front-Ends eng mit unserer täglichen Entwicklung verbunden? Schauen wir uns diese Datei genauer an.​

Wenn wir ein neues Projekt erstellen, hilft uns das Gerüst häufig dabei, eine Konfigurationsdatei package.jaon zu initialisieren, die sich im Stammverzeichnis des Projekts befindet. Wenn ein Projekt mit dem react Scaffold (create-react-app) initialisiert wird, lautet der Inhalt der Datei package.json wie folgt:

{
  "Name": "meine App",
  "version": "0.1.0",
  "privat": wahr,
  "Abhängigkeiten": {
    "@testing-library/jest-dom": "^5.14.1",
    "@testing-library/react": "^11.2.7",
    "@testing-library/user-event": "^12.8.3",
    "reagieren": "^17.0.2",
    "reagieren-dom": "^17.0.2",
    "Reaktionsskripte": "4.0.3",
    "Web-Vitalwerte": "^1.1.2"
  },
  "Skripte": {
    "Start": "React-Scripts starten",
    "Build": "React-Scripts erstellen",
    "Test": "React-Scripts-Test",
    "auswerfen": "React-Scripts auswerfen"
  },
  "eslintConfig": {
    "erweitert": [
      "React-App",
      „Reagieren-App/Jest“
    ]
  },
  "Browserliste": {
    "Produktion": [
      ">0,2 %",
      "nicht tot",
      "nicht alle op_mini"
    ],
    "Entwicklung": [
      "letzte 1 Chrome-Version",
      "letzte 1 Firefox-Version",
      „letzte 1 Safari-Version“
    ]
  }
}

Wenn wir ein neues Projekt lokal klonen, müssen wir npm install (yarn install) ausführen, um die vom Projekt benötigten Abhängigkeitsdateien zu installieren. Wenn dieser Befehl ausgeführt wird, werden die erforderlichen Module automatisch gemäß den Konfigurationsinformationen in der Datei package.json heruntergeladen, dh der für das Konfigurationsprojekt erforderlichen Ausführungs- und Entwicklungsumgebung.​

Allgemeine Konfigurationselemente in package.json sind wie folgt:

1. Erforderliche Attribute

Die beiden wichtigsten Felder in package.json sind name und version . Sie sind beide erforderlich. Ohne sie kann der Befehl npm install nicht normal ausgeführt werden. npm gibt an, dass die Datei package.json den Namen und die Versionsnummer als eindeutige Kennung verwendet.

1. Name

name ist leicht zu verstehen, es ist der Name des Projekts, es ist eine Zeichenfolge.

Bei der Benennung des name müssen Sie auf folgende Punkte achten:

• Der Name muss höchstens 214 Zeichen lang sein, darf nicht mit „.“ oder „_“ beginnen und darf keine Großbuchstaben enthalten (da das Paket beim Veröffentlichen auf npm eine eigene URL basierend auf dieser Eigenschaft erhält und daher non-url-safe enthalten darf);
• Der Name kann als Argument require ("") übergeben werden, um das Modul zu importieren. Er sollte daher so kurz und semantisch wie möglich sein.
• Der Name darf nicht mit dem anderer Module identisch sein. Mit npm view können Sie prüfen, ob der Modulname wiederholt wird. Wenn nicht, wird eine 404-Fehlermeldung angezeigt:
  

Wenn sich im npm Paket ein entsprechendes Paket befindet, werden die detaillierten Informationen des Pakets angezeigt:

Tatsächlich werden viele der von uns entwickelten Projekte nicht auf npm veröffentlicht. Daher ist es möglicherweise nicht so wichtig, ob der Name ein Standard ist, und es hat keinen Einfluss auf den normalen Betrieb des Projekts. Wenn Sie es auf npm veröffentlichen müssen, muss das name die Anforderungen erfüllen.

2. Version

version Versionsfeld gibt die Versionsnummer des Projektpakets an, die eine Zeichenfolge ist. Nach jeder Projektänderung, kurz vor der Veröffentlichung, muss die Projektversionsnummer synchron geändert werden.

Die Spezifikationen zur Verwendung der Versionsnummern lauten wie folgt:

• Die Versionsnummer wird gemäß der Spezifikation „Semantic Versioning 2.0.0“ im Format Hauptversionsnummer.Nebenversionsnummer.Revisionsnummer vergeben. Normalerweise bedeutet eine Änderung der Hauptversionsnummer eine wesentliche Funktionsänderung, eine Änderung der Nebenversionsnummer das Hinzufügen neuer Funktionen und eine Änderung der Revisionsnummer das Beheben einiger Fehler.
• Wenn eine Version größere Änderungen aufweist und instabil ist und möglicherweise nicht die erwarteten Kompatibilitätsanforderungen erfüllt, muss eine Vorabversion veröffentlicht werden. Die Vorabversion wird nach der Versionsnummer hinzugefügt, und die durch Punkte getrennten Kennungen und Informationen zur Versionskompilierung werden durch ein "-"-Zeichen verbunden: interne Version (Alpha), öffentliche Betaversion (Beta) und Kandidatenversion (rc, Release Candiate).
  

Sie können die Versionsinformationen des npm-Pakets mit dem folgenden Befehl anzeigen, am Beispiel von react:

// Die neueste Version anzeigen npm view react version
// Alle Versionen anzeigen npm view react Versionen

Wenn der zweite Befehl ausgeführt wird, ist das Ergebnis wie folgt:

2. Beschreibungsinformationen

Es gibt fünf Konfigurationsfelder in package.jaon , die sich auf die Projektpaketbeschreibungsinformationen beziehen. Sehen wir uns die Bedeutung dieser Felder im Einzelnen an.

1. Beschreibung

Das description wird verwendet, um dieses Projektpaket zu beschreiben. Es ist eine Zeichenfolge, mit der andere Entwickler unser Projektpaket in npm Suche finden können.

2. Schlüsselwörter

keywords ist ein Zeichenfolgenarray, das die Schlüsselwörter dieses Projektpakets darstellt. Ebenso wie description dient es dazu, die Sichtbarkeit des Projektpakets zu erhöhen.

Nachfolgend finden Sie die Beschreibung und Schlüsselwörter des eslint-Pakets:

3. Autor

author wie der Name schon sagt, der Autor und gibt den Urheber des Projektpakets an. Es gibt zwei Formen, eine davon ist das Zeichenfolgenformat:

"Autor": "CUGGZ <[email protected]> (https://juejin.cn/user/3544481220801815)"

Die andere ist die Objektform:

"Autor": {
  "Name" : "CUGGZ",
  "E-Mail": "[email protected]",
  "URL": "https://juejin.cn/user/3544481220801815"
}

4. Mitwirkende

contributors stellt die Mitwirkenden des Projektpakets dar. Im Gegensatz zum Autor ist dieses Feld ein Array, das alle Mitwirkenden enthält. Es gibt auch zwei Schreibweisen:

"Mitwirkende": [
  „CUGGZ0 <[email protected]> (https://juejin.cn/user/3544481220801815)“,
  „CUGGZ1 <[email protected]> (https://juejin.cn/user/3544481220801815)“
 ]

"Mitwirkende": [
  {
   "Name" : "CUGGZ0",
   "E-Mail": "[email protected]",
   "URL": "https://juejin.cn/user/3544481220801815"
 },
  {
   "Name" : "CUGGZ1",
   "E-Mail": "[email protected]",
   "URL": "https://juejin.cn/user/3544481220801815"
 }
 ]

5. Homepage

homepage ist die Homepage-Adresse des Projekts, bei der es sich um eine Zeichenfolge handelt.

6. Aufbewahrungsort

repository stellt die Adresse des Repositorys dar, in dem der Code gespeichert ist, und wird normalerweise in zwei Formen geschrieben. Die erste ist in Zeichenfolgenform:

"Repository": "https://github.com/facebook/react.git"

Darüber hinaus können Sie das Versionskontrollsystem auch explizit festlegen, in diesem Fall in Form eines Objekts:

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

7. Fehler

bugs stellt die Adresse für die Meldung von Problemen im Projekt dar. Dieses Feld ist ein Objekt, das eine Adresse für die Meldung von Problemen und eine E-Mail-Adresse für Feedback hinzufügen kann:

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

Die häufigsten bugs finden Sie auf der issues -Seite in Github . Oben finden Sie die Adresse der issues -Seite von react .

3. Abhängigkeitskonfiguration

Normalerweise hängt unser Projekt von einem oder mehreren externen Abhängigkeitspaketen ab. Abhängig von der unterschiedlichen Verwendung der Abhängigkeitspakete können sie unter den folgenden fünf Eigenschaften konfiguriert werden: dependencies , devDependencies , peerDependencies , bundledDependencies , optionalDependencies . Sehen wir uns die Bedeutung jedes Attributs an.

1. Abhängigkeiten

Das Feld dependencies deklariert die erforderlichen Abhängigkeitspakete für die Produktionsumgebung des Projekts. Wenn Sie ein npm Paket mit npm oder yarn installieren, wird das NPM-Paket automatisch in dieses Konfigurationselement eingefügt:

npm install <PAKETNAME>
yarn add <PAKETNAME>

Wenn Sie beim Installieren von Abhängigkeiten den Parameter --save verwenden, werden die neu installierten npm Pakete auch in dependencies geschrieben.

npm install --save <PAKETNAME>

Der Wert dieses Felds ist ein Objekt, dessen Mitglieder aus Modulnamen und entsprechenden Versionsanforderungen bestehen, die die abhängigen Module und ihre Versionsbereiche angeben.

"Abhängigkeiten": {
   "reagieren": "^17.0.2",
   "reagieren-dom": "^17.0.2",
   "Reaktionsskripte": "4.0.3",
},

Jede Konfiguration ist hier ein key-value Wert), wobei key den Modulnamen und value die Versionsnummer des Moduls darstellt.

Die Versionsnummer folgt dem Format Hauptversionsnummer.Nebenversionsnummer.Revisionsnummer:

• Behobene Version: Die obige react-scripts -Version 4.0.3 ist eine behobene Version. Bei der Installation wird nur diese angegebene Version installiert.
• Tilde: Beispielsweise bedeutet ~4.0.3, dass die neueste Version von 4.0.x (nicht weniger als 4.0.3) installiert wird, was bedeutet, dass die Haupt- und Nebenversionsnummern während der Installation nicht geändert werden.
• Nummer einfügen: Beispielsweise bedeutet die obige React-Version ^17.0.2, dass die neueste Version von 17.xx (nicht niedriger als 17.0.2) installiert wird. Dies bedeutet, dass die Hauptversionsnummer während der Installation nicht geändert wird. Wenn die Hauptversionsnummer 0 ist, ist das Verhalten der Caret- und Tilde-Zeichen dasselbe.
• latest: Installieren Sie die neueste Version.
• Es ist wichtig zu beachten, dass Sie keine Test- oder Übergangsabhängigkeiten in dependencies einfügen sollten, um unerwartete Probleme in der Produktionsumgebung zu vermeiden.

2. Entwicklungsabhängigkeiten

devDependencies deklariert die während der Entwicklungsphase erforderlichen Abhängigkeitspakete wie Webpack , Eslint , Babel usw., um die Entwicklung zu unterstützen. Sie unterscheiden sich von dependencies dadurch, dass sie nur auf Ihrem Entwicklungscomputer installiert werden müssen und nicht erforderlich sind, um Ihren Code in der Produktion auszuführen. Diese Pakete werden beim Verpacken und Starten nicht benötigt, daher können Sie diese Abhängigkeiten zu devDependencies hinzufügen. Diese Abhängigkeiten werden weiterhin installiert und verwaltet, wenn Sie npm install lokal angeben, aber sie werden nicht in der Produktionsumgebung installiert.

Wenn Sie Pakete mit npm oder yarn installieren, werden die neu installierten npm-Pakete automatisch in diese Liste eingefügt, indem Sie die folgenden Parameter angeben:

npm install --save-dev <PAKETNAME>
yarn add --dev <PAKETNAME>

"devAbhängigkeiten": {
  "autoprefixer": "^7.1.2",
  "babel-core": "^6.22.1"
}

3. Peer-Abhängigkeiten

In manchen Fällen hängen sowohl unser Projekt als auch die Module, von denen es abhängt, von einem anderen Modul ab, die Versionen, von denen sie abhängen, sind jedoch unterschiedlich. Beispielsweise hängt unser 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 koexistieren 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 vom Plug-In verwendet, um die erforderliche Version des Haupttools anzugeben.

"Name": "Chai wie versprochen",
"Peer-Abhängigkeiten": {
   "chai": "1.x"
}

Der obige Code gibt an, dass bei der Installation des Moduls chai-as-promised das Hauptprogramm „chai“ zusammen mit der Installation installiert werden muss und dass die Version von „chai“ 1.x sein muss. Wenn das Projekt eine Abhängigkeit von Version 2.0 von Chai angibt, wird ein Fehler gemeldet.

Beachten Sie, dass ab npm Version 3.0 peerDependencies nicht mehr standardmäßig installiert werden.

4. optionaleAbhängigkeiten

Wenn npm weiter ausgeführt werden soll, wenn das Paket nicht gefunden werden kann oder die Installation des Pakets fehlschlägt, können Sie das Paket in das optionalDependencies Objekt einfügen. Die Pakete im optionalDependencies -Objekt überschreiben die Pakete mit demselben Namen in dependencies , sodass Sie es nur an einer Stelle festlegen müssen.

Es ist zu beachten, dass die Abhängigkeiten in optionalDependencies möglicherweise nicht erfolgreich installiert werden und daher eine Ausnahmebehandlung erforderlich ist. Andernfalls wird beim Abrufen dieser Abhängigkeit ein Fehler gemeldet, wenn sie nicht abgerufen werden kann.

5. gebündelte Abhängigkeiten

Die oben aufgeführten abhängigkeitsbezogenen Konfigurationselemente sind alle Objekte, während das Konfigurationselement bundledDependencies ein Array ist, in dem Sie einige Module angeben können, die beim Freigeben dieses Pakets zusammen gepackt werden.

Es ist zu beachten, dass die Werte in diesem Feld-Array in dependencies und devDependencies deklarierte Pakete sein müssen.

6. Motoren

Wenn wir einige alte Projekte warten, haben wir möglicherweise besondere Anforderungen an npm Paketversion oder die Node-Version. Wenn die Bedingungen nicht erfüllt sind, kann das Projekt möglicherweise nicht ausgeführt werden. Damit das Projekt sofort funktioniert, können Sie im Feld engines die spezifische Versionsnummer angeben:

"Motoren": {
 "Knoten": ">=8.10.3 <12.13.0",
  "npm": ">=6.9.0"
}

Hinweis: Engines dienen nur zur Erklärung. Auch wenn die vom Benutzer installierte Version die Anforderungen nicht erfüllt, hat dies keine Auswirkungen auf die Installation abhängiger Pakete.

4. Skriptkonfiguration

1. Skripte

scripts ist ein integrierter Skripteintrag in package.json . Es handelt sich um key-value Paar-Konfiguration. Der Schlüssel ist ein ausführbarer Befehl, der über npm run ausgeführt werden kann. Zusätzlich zum Ausführen grundlegender scripts können Sie auch Pre- und post kombinieren, um Pre- und Post-Operationen abzuschließen.

Sehen wir uns zunächst eine Reihe von scripts an:

"Skripte": {
 "dev": "Knotenindex.js",
  "predev": "Knoten vorIndex.js",
  "postdev": "Knoten nachIndex.js"
}

In jeder dieser drei js-Dateien befindet sich eine console :

// index.js
console.log("Skripte: index.js")
// vorIndex.js
console.log("Skripte: vor index.js")
// nachIndex.js
console.log("Skripte: nach index.js")

Wenn wir den Befehl npm run dev ausführen, lautet die Ausgabe wie folgt:

Skripte: vor index.js
Skripte: index.js
Skripte: nach index.js

Wie Sie sehen, werden alle drei Befehle ausgeführt und die Ausführungsreihenfolge ist predev→dev→postdev . Wenn scripts Skriptbefehle eine bestimmte Reihenfolge haben, können Sie diese drei Konfigurationselemente verwenden, um die Ausführungsbefehle separat zu konfigurieren.

Durch Konfigurieren der Skripteigenschaft können Sie einige allgemeine Betriebsbefehle definieren:

"Skripte": {
  "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
  "Start": "npm-Ausführungs-Entwickler",
  "Einheit": "jest --config test/unit/jest.conf.js --coverage",
  "Test": "npm-Ausführungseinheit",
  "lint": "eslint --ext .js,.vue src test/unit",
  "Build": "Knotenbuild/build.js"
}

Diese Skripte sind Befehlszeilen-Anwendungen. Sie können durch den Aufruf von npm run XXX oder yarn XXX ausgeführt werden, wobei XXX der Name des Befehls ist. Beispiel: npm run dev . Wir können für den Befehl einen beliebigen Namen verwenden und das Skript kann alles sein.

Die ordnungsgemäße Verwendung dieses Felds kann die Entwicklungseffizienz erheblich verbessern.

2. Konfiguration

Das config wird verwendet, um die Konfigurationsparameter scripts Skriptlaufzeit zu konfigurieren, wie unten gezeigt:

"Konfiguration": {
 "Hafen": 3000
}

Wenn Sie npm run start ausführen, wird das Port-Feld npm_package_config_port zugeordnet:

Konsole.log(Prozess.Umgebung.npm_package_config_port) // 3000

Benutzer können den Portwert überschreiben, indem sie npm config set foo:port 3001 ausführen.

5. Dateien und Verzeichnisse

Werfen wir einen Blick auf die Eigenschaften bezüglich Dateien und Verzeichnissen in package.json .

1. Haupt

Das main wird verwendet, um die zu ladende Eintragsdatei anzugeben, die sowohl in browser als auch in Node -Umgebungen verwendet werden kann. Wenn wir das Projekt als npm Paket veröffentlichen und require zum Importieren des NPM-Pakets verwenden, wird module.exports der im Hauptfeld aufgeführten Datei zurückgegeben. Wenn dieses Feld nicht angegeben ist, ist die Standardeinstellung index.js im Stammverzeichnis des Projekts. Falls es nicht gefunden wird, wird ein Fehler gemeldet.​

Der Wert dieses Feldes ist eine Zeichenfolge:

"Haupt": "./src/index.js",

2. Browser

browser Browserfeld kann die Einstiegsdatei npm Pakets in browser Browserumgebung definieren. Wenn das npm-Paket nur auf der Webseite verwendet wird und die Verwendung auf der Serverseite strengstens untersagt ist, definieren Sie die Eingabedatei browser .

"Browser": "./src/index.js"

3. Modul

module Modulfeld kann die ESM-Spezifikationseintragsdatei des npm-Pakets definieren, die sowohl in browser als auch in der Knotenumgebung verwendet werden kann. Wenn das npm-Paket ein ESM-kompatibles Paket exportiert, verwenden Sie module , um die Eintragsdatei zu definieren.

"Modul": "./src/index.mjs",

Hinweis: .js-Dateien verwenden die commonJS -Standardsyntax (require('xxx')) und .mjs-Dateien verwenden die ESM-Standardsyntax (import 'xxx').​

Die Konfigurationen der drei oben genannten Eintragsdateien sind unterschiedlich, insbesondere in unterschiedlichen Verwendungsszenarien. Wenn Sie in einer Webumgebung Loader zum Laden von ESM (ES-Modul) verwenden, lautet die Ladereihenfolge dieser drei Konfigurationen browser→module→main . Wenn Sie require zum Laden CommonJS -Modulen verwenden, lautet die Ladereihenfolge main→module→browser .​

Wenn Webpack ein Projekt erstellt, gibt es eine Zieloption, die standardmäßig auf „Web“ eingestellt ist, d. h. auf das Erstellen einer Webanwendung. Wenn Sie einige isomorphe Projekte, z. B. Knotenprojekte, kompilieren müssen, müssen Sie zum Erstellen nur die Zieloption von webpack.config.js auf Knoten setzen. Wenn Sie CommonJS-Module oder ESM in einer Node-Umgebung laden, ist nur das Hauptfeld gültig.

4. bin

Das Feld „bin“ wird verwendet, um den Speicherort der ausführbaren Datei anzugeben, die jedem internen Befehl entspricht:

"bin": {
  "someTool": "./bin/someTool.js"
}

Hier ist die ausführbare Datei, die dem Befehl someTool entspricht, someTool.js im Bin-Verzeichnis, someTool.js erstellt einen symbolischen Link node_modules/.bin/someTool . Da 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. Daher kann folgendes abgekürzt werden:

Skripte: {  
  Start: './node_modules/bin/someTool.js build'
}

// Kurzschriftskripte: {  
  Start: „someTool build“
}

Alle Befehle im Verzeichnis node_modules/.bin/ können im Format npm run [Befehl] ausgeführt werden.

Die obige Konfiguration stellt ein Bin-Feld in package.json bereit, das einem lokalen Dateinamen zugeordnet ist. Das npm-Paket verknüpft diese Datei dann mit Präfix/Fix für den globalen Import. Oder verlinken Sie zur Verwendung in diesem Projekt auf Ihre lokale node_modules/.bin/ -Datei.

5. Dateien

Die Dateikonfiguration ist ein Array, das die Liste der Dateien beschreibt, die bei der Installation npm Pakets als Abhängigkeitspaket angegeben werden müssen. Wenn das npm Paket veröffentlicht wird, werden die in „files“ angegebenen Dateien auf npm Server übertragen. Wenn ein Ordner angegeben ist, werden alle Dateien in diesem Ordner übermittelt.

"Dateien": [
    "LIZENZ",
    "Readme.md",
    "index.js",
    "lib/"
 ]

Wenn es Dateien gibt, die Sie nicht übermitteln möchten, können Sie im Stammverzeichnis des Projekts eine neue .npmignore Datei erstellen und die Dateien beschreiben, die nicht übermittelt werden müssen, um zu verhindern, dass Junk-Dateien an npm gesendet werden. Das Format dieser Datei ähnelt .gitignore . In diese Datei geschriebene Dateien werden ausgeschlossen, auch wenn sie in das Dateiattribut geschrieben werden. Sie können beispielsweise in diese Datei schreiben:

Knotenmodule
.vscode

bauen

.DS_Store

6. Mann

Der Befehl man ist ein Hilfebefehl in Linux. Mit diesem Befehl können Sie Informationen wie Befehlshilfe, Konfigurationsdateihilfe und Programmierhilfe in Linux anzeigen. Wenn node.js Modul ein globales Kommandozeilentool ist, können Sie über das man-Attribut die Dokumentadresse angeben, nach der der man-Befehl in package.json sucht:

"Mann": [
 "./man/npm-access.1",
 „./man/npm-audit.1“
]

Das Feld man kann eine oder mehrere Dateien angeben. Wenn man {Paketname} ausgeführt wird, wird dem Benutzer der Dokumentinhalt angezeigt.

Notiz:

• Die Man-Datei muss mit einer Nummer enden und kann das Suffix .gz verwenden, wenn sie komprimiert ist. Diese Nummer gibt an, in welchen Man-Abschnitt die Datei installiert wird. Wenn der Man-Dateiname nicht mit dem Modulnamen beginnt, wird bei der Installation das Modulnamenpräfix hinzugefügt.
  

Für die obige Konfiguration können Sie den folgenden Befehl verwenden, um das Dokument anzuzeigen:

man npm-zugriff
Mann npm-audit

7. Verzeichnisse

Das Feld directories wird verwendet, um das Projektverzeichnis anzugeben. Node.js-Module werden basierend auf CommonJS Modularisierungsspezifikation implementiert und müssen der CommonJS-Spezifikation strikt folgen. Zusätzlich zur Paket-Projektbeschreibungsdatei package.json muss das Modulverzeichnis auch die folgenden Verzeichnisse enthalten:

• bin: Verzeichnis zum Speichern ausführbarer Binärdateien
• lib: Verzeichnis, in dem der JS-Code gespeichert ist
• doc: Verzeichnis zum Speichern von Dokumenten
• test: Verzeichnis zum Speichern von Unit-Testfallcodes
• ...
  

Im eigentlichen Projektverzeichnis müssen wir es möglicherweise nicht gemäß dieser Spezifikation benennen. Daher können wir den Dateipfad für jedes Verzeichnis im Feld directories angeben:

"Verzeichnisse": {
    "bin": "./bin",
    "lib": "./lib",
    "doc": "./doc",
    "Prüfung" "./Test",
    "Mann": "./Mann"
},

Dieses Attribut hat derzeit keinen praktischen Nutzen, es ist jedoch nicht ausgeschlossen, dass es in Zukunft zu sinnvolleren Verwendungszwecken kommt.

6. Release-Konfiguration

Werfen wir einen Blick auf die Konfiguration im Zusammenhang mit der Veröffentlichung npm Projektpakets.

1. privat

Das private Feld verhindert, dass wir versehentlich private Bibliotheken auf dem NPM-Server veröffentlichen. Setzen Sie dieses Feld einfach auf „true“:

"privat": wahr

2. bevorzugenGlobal

Das Feld preferGlobal gibt an, dass eine Warnung angezeigt wird, wenn der Benutzer das Modul nicht als globales Modul installiert (sofern es auf „true“ gesetzt ist). Es hindert Benutzer nicht wirklich daran, Teilinstallationen durchzuführen, sondern stellt nur eine Erinnerung dar, um Missverständnissen vorzubeugen:

"preferGlobal": wahr

3. Konfiguration veröffentlichen

Die publishConfig Konfiguration wird wirksam, wenn das Modul veröffentlicht wird, und wird verwendet, um beim Veröffentlichen eine Sammlung von Konfigurationselementen festzulegen. Wenn Sie nicht möchten, dass das Modul standardmäßig als das neueste markiert wird, oder es nicht in einem öffentlichen Repository veröffentlichen möchten, können Sie hier das Tag oder die Repository-Adresse konfigurieren. Eine detailliertere Konfiguration finden Sie unter npm-config .​

Normalerweise wird publishConfig mit private verwendet. Wenn Sie möchten, dass das Modul nur in einem bestimmten npm Repository veröffentlicht wird, können Sie es wie folgt konfigurieren:

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

4. Betriebssystem

Im Feld „OS“ können wir festlegen, auf welchen Betriebssystemen das npm Paket verwendet werden kann und auf welchen nicht. Wenn wir ein npm Paket entwickeln möchten, das nur unter Linux läuft, wird Benutzern, die Windows Systeme verwenden, empfohlen, es nicht zu installieren, um unnötige Ausnahmen zu vermeiden. In diesem Fall können Sie die Betriebssystemkonfiguration verwenden:

"os" ["linux"] // Anwendbare Betriebssysteme "os" ["!win32"] // Deaktivierte Betriebssysteme

5. Zentralprozessor

Diese Konfiguration ähnelt der Betriebssystemkonfiguration. Durch die Verwendung CPU kann die Installationsumgebung des Benutzers genauer eingeschränkt werden:

"cpu" ["x64", "AMD64"] // Anwendbare CPU
"cpu" ["!arm", "!mips"] // CPU deaktiviert

Wie Sie sehen, besteht der Unterschied zwischen der Blacklist und der Whitelist darin, dass der Blacklist ein „!“ vorangestellt ist.

6. Lizenz

license Lizenzfeld wird verwendet, um die Open-Source-Vereinbarung der Software anzugeben. Die Open-Source-Vereinbarung beschreibt die Rechte, die andere nach Erhalt des Codes haben, welche Vorgänge mit dem Code ausgeführt werden können und welche Vorgänge verboten sind.

Gängige Protokolle sind die folgenden:

• MIT: Solange Benutzer den Copyright-Hinweis und den Lizenzhinweis in ihre Kopien des Projekts aufnehmen, können sie mit Ihrem Code machen, was sie wollen, und Sie müssen dafür keine Verantwortung übernehmen.
• Apache: Ähnlich wie MIT, enthält aber auch Bedingungen für Mitwirkende, um Benutzern Patentlizenzen bereitzustellen.
• GPL: Benutzer, die den Projektcode ändern, müssen ihre Änderungen veröffentlichen, wenn sie den Quellcode oder Binärcode weitergeben.
  

Das Feld kann wie folgt deklariert werden:

"Lizenz": "MIT"

7. Konfiguration durch Drittanbieter

Die Datei package.json kann auch befehlsspezifische Konfigurationen enthalten, wie etwa Babel , ESLint usw. Jeder von ihnen hat einzigartige Eigenschaften, wie etwa eslintConfig , babel usw. Sie sind befehlsspezifisch. Informationen zu ihrer Verwendung finden Sie in der entsprechenden Befehls-/Projektdokumentation. Sehen wir uns einige häufig verwendete Konfigurationselemente von Drittanbietern an.

1. Typisierungen

Das Feld „Typings“ wird verwendet, um die TypeScript-Eintragdatei anzugeben:

"Typisierungen": "Typen/index.d.ts",

Die Funktion dieses Feldes ist die gleiche wie die main .

2. eslintConfig

Die Konfiguration von eslint kann in eine separate Konfigurationsdatei .eslintrc.json oder in das Konfigurationselement eslintConfig der Datei package.json geschrieben werden.

"eslintConfig": {
      "root": wahr,
      "Umgebung": {
        "Knoten": wahr
      },
      "erweitert": [
        "Plugin:vue/essential",
        „eslint:empfohlen“
      ],
      "Regeln": {},
      "Parseroptionen": {
        "Parser": "babel-eslint"
     },
}

3. Babel

Babel wird verwendet, um die Kompilierungskonfiguration von Babel anzugeben. Der Code lautet wie folgt:

"babel": {
 "Voreinstellungen": ["@babel/preset-env"],
 "Plugins": [...]
}

4. auspacken

Verwenden Sie dieses Feld, um den CDN-Dienst für alle Dateien auf npm zu aktivieren. Der CND-Dienst wird von unpkg bereitgestellt:

"unpkg": "dist/vue.js"

5. lint-staged

lint-staged ist ein Tool, das linters auf Git-Staging-Dateien ausführt. Nach der Konfiguration kann bei jeder Änderung einer Datei eine Lint-Prüfung auf alle Dateien durchgeführt werden. Es wird normalerweise in Verbindung mit gitHooks verwendet.

"lint-staged": {
 "*.js": [
   "eslint --fix",
    "git add"
  ]
}

Bei der Verwendung lint-staged werden bei jeder Codeübermittlung nur die aktuell geänderten Dateien überprüft.

6. gitHooks

gitHooks wird ein Hook definiert, der vor dem Commit ESlint-Prüfungen durchführt. Nach der Ausführung des Lint-Befehls werden die Dateien im temporären Speicherbereich automatisch repariert. Die reparierten Dateien werden nicht im Staging-Bereich gespeichert. Sie müssen daher den Befehl git add verwenden, um die reparierten Dateien wieder zum Staging-Bereich hinzuzufügen. Wenn nach der Ausführung des pre-commit -Befehls keine Fehler auftreten, wird der Git-Commit-Befehl ausgeführt:

"gitHooks": {
 „Vorab-Commit“: „lint-staged“
}

Hier muss mit dem oben genannten lint-staged zusammengearbeitet werden, um den Code zu überprüfen.

7. Browserliste

browserslist wird verwendet, um anzugeben, welche Browser und Versionen unterstützt werden. Es wird von Babel , Autoprefixer und anderen Tools verwendet, um den Zielbrowsern die erforderlichen polyfill und fallback hinzuzufügen. Der Wert dieses Felds im obigen Beispiel lautet beispielsweise:

"Browserliste": {
  "Produktion": [
    ">0,2 %",
    "nicht tot",
    "nicht alle op_mini"
  ],
  "Entwicklung": [
    "letzte 1 Chrome-Version",
    "letzte 1 Firefox-Version",
    „letzte 1 Safari-Version“
  ]
}

Hier wird ein Objekt angegeben, das die Browseranforderungen für Produktions- und Entwicklungsumgebungen definiert. development gibt die letzte Version der Browser chrome , Firefox und safari an, die in der Entwicklungsumgebung unterstützt werden. Diese Eigenschaft ist ein Konfigurationstool zum Teilen von Zielbrowsern und Knotenversionen zwischen verschiedenen Front-End-Tools. Es wird von vielen Front-End-Tools wie Babel und Autoprefixer verwendet.

Dies ist das Ende dieses Artikels über den Front-End-JavaScript-Butler package.json. Weitere relevante Inhalte zum Front-End-Butler package.json finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!