Eine eingehende Analyse der package.json-Datei

Verstehen Sie package.json.

Im Stammverzeichnis jedes Projekts (von npm oder anderen nodejs-Projekten heruntergeladenes Paket) befindet sich im Allgemeinen eine package.json-Datei, die die verschiedenen für das Projekt erforderlichen Module sowie die Projektkonfigurationsinformationen definiert ( Metadaten wie Name, Version, Lizenz, wie das Projekt gestartet wird, Skripte ausgeführt werden usw.). Der Befehl npm install lädt automatisch die erforderlichen Module basierend auf dieser Konfigurationsdatei herunter.

Die Datei package.json ist ein JSON-Objekt und jedes Mitglied des Objekts ist eine Einstellung des aktuellen Projekts. name ist beispielsweise der Projektname version ist die Version (im Format „Hauptversion.Nebenversion.Nebenversion“). Es wird auch mehrere Rollen im Projektlebenszyklus spielen, einschließlich Entwicklung, Test und Online-Versionen.

package.json fungiert

• als Beschreibungsdatei, die die Pakete beschreibt, von denen Ihr Projekt abhängt.
• Sie ermöglicht uns die Verwendung von „semantischen Versionierungsregeln“ (später beschrieben), um die Version der abhängigen Pakete Ihres Projekts anzugeben,
• damit Ihr Build besser mit anderen Entwicklern kommunizieren kann . Zur einfachen Wiederverwendung freigeben

So erstellen Sie package.json

1. Verwenden Sie das Befehlszeilentool client CLI

npm init.

Dadurch wird der Befehlszeilenfragebogen gestartet, der package.json in dem Verzeichnis erstellt, in dem Sie den Befehl gestartet haben.

Front-End-Eintrag (vue) zum Meisterkurs: Lernen eingeben

2. Standardwert erstellen

Um den Standardwert package.json zu erhalten, führen Sie bitte npm init mit --yes oder -y aus:

npm init -y

Diese Methode verwendet package.json aus dem aktuellen Verzeichnis. Die aus dem Verzeichnis extrahierten Informationen generieren Standardwerte und überspringen den Schritt der Beantwortung von Fragen.

3. Erstellen Sie manuell

eine neue package.json-Datei direkt im Projektstammverzeichnis und geben Sie dann den relevanten Inhalt ein. Weitere Informationen finden Sie in den Hinweisen zu package.json unten.

Ausführliche Erläuterung der allgemeinen Felder in package.json-Dateien.

1. Name

ist ein Pflichtfeld. Dabei handelt es sich um den Namen des aktuellen Moduls/Pakets. Die Länge darf höchstens 214 Zeichen betragen ) oder „_“ (Unterstrich) und darf keine Großbuchstaben enthalten.

Dieser Name kann als Parameter an require() übergeben werden, daher sollte er kurz, aber dennoch aussagekräftig sein.

2. Version

ist ein Pflichtfeld, die Versionsnummer des aktuellen Pakets. Der Standardwert ist 1.0.0 , wenn es zum ersten Mal erstellt wird.

Die Version muss durch ein Node-Semver-Modul auflösbar sein, von dem npm abhängt. Definiert den Versionsiterationsfortschritt des aktuellen Projekts. (Folgen Sie dem Format „Hauptversion. Nebenversion. Nebenversion“)

Vielleicht achten viele Freunde jetzt nicht mehr auf die Versionsnummer oder kümmern sich nicht darum und verwenden lieber die Versionsnummer des Produkts oder den Git Hashcode-Methode.

3. Das

optionale Beschreibungsfeld muss eine Zeichenfolge sein. Die Beschreibungsinformationen des aktuellen Pakets sind eine Zeichenfolge. Es hilft Benutzern, das Paket zu finden, wenn sie die NPM-Suche verwenden.

Wenn in package.json keine description vorhanden sind, verwendet npm die erste Zeile von README.md im Projekt als Beschreibungsinformationen. Diese Beschreibungsinformationen helfen anderen bei der Suche nach Ihrem Projekt. Es wird daher empfohlen, description gut zu formulieren.

4. Das

optionale Hauptfeld gibt die Eintragsdatei für das Laden des Projekts an.

Der Standardwert dieses Felds ist index.js im Stammverzeichnis des Moduls.

5. Das

optionale Feld „ scripts “ ist ein Hash-Objekt, das aus Skriptbefehlen besteht. Sie werden in verschiedenen Lebenszyklen des Pakets ausgeführt. Der Schlüssel ist das Lebenszyklusereignis und der Wert ist der auszuführende Befehl. Gibt die npm-Befehlszeilenabkürzung zum Ausführen des Skriptbefehls an. Start gibt beispielsweise den Befehl an, der beim Ausführen von npm run start ausgeführt werden soll. Wir können den Befehl anpassen, mit dem das Skript ausgeführt werden soll.

Referenz: http://www.ruanyifeng.com/blog/2016/10/npm_scripts.html

Skriptkonfigurationsausführungsskript

,

• um

• 2. die Datei unter node_modules/.bin auszuführen.

Wenn ich npm run ausführe, wird automatisch eine neue Shell erstellt und der angegebene Skriptbefehl wird in dieser Shell ausgeführt. Solange der Befehl daher von Shell (normalerweise Bash) ausgeführt werden kann, kann er in das npm-Skript geschrieben werden. kopiert auch node_modules/.bin im aktuellen Verzeichnis in den Pfad des aktuellen Systems (es handelt sich nur um eine temporäre Kopie. Nach Abschluss der Ausführung wird die PATH-Variable in ihren ursprünglichen Zustand zurückversetzt), also alle Skripte in den node_modules /.bin Unterverzeichnis des aktuellen Verzeichnisses. Alle können direkt über den Skriptnamen aufgerufen werden, ohne einen Pfad hinzuzufügen.

Beispiel:

Wenn wir node zum Ausführen eines node server.js -Dienstes verwenden, können wir node + 文件auch verwenden, um die Front-End-Datei webpack-dev-server zu packen webpack-dev-server müssen installiert werden

.   
    „build“: „webpack --mode=development“,
    „dev“: „webpack-dev-server --mode=development --contentBase=./dist“,
    „server“: „Knoten app.js“
  }

Wir geben npm run server in das Befehlszeilentool ein und node app.js wird aufgerufen, um uns bei der Ausführung zu helfen.

Kurzform:

npm start ist npm run start
npm stop ist die Abkürzung für npm run stop npm test ist die Abkürzung für npm run test npm restart ist die Abkürzung für npm run stop && npm run restart && npm run start

Häufig verwendete Skripte ----- Online-Sammlungsübertragung

// Verzeichnis löschen „clean“: „rimraf dist/*“,

// Einen HTTP-Dienst „serve“ lokal erstellen: „http-server -p 9090 dist/“,

//Öffnen Sie den Browser „open:dev“: „opener http://localhost:9090“,

//Aktualisieren Sie „livereload“ in Echtzeit: „live-reload --port 9091 dist/“,

// HTML-Datei erstellen „build:html“: „jade index.jade > dist/index.html“,

// Solange sich die CSS-Datei ändert, führen Sie den Build erneut aus. „watch:css“: „watch ‚npm ​​run build:css‘ asset/styles/“,

// Solange sich die HTML-Datei ändert, führen Sie den Build „watch:html“ erneut aus: „watch ‚npm ​​run build:html‘ asset/html“,

//Bereitstellung auf Amazon S3
„deploy:prod“: „s3-cli sync ./dist/ s3://example-com/prod-site/“,

//Favicon erstellen
„build:favicon“: „node scripts/favicon.js“,

„start“: „cross-env NODE_ENV=Produktionsknoten server/index.js“,

6. Abhängigkeiten und devDependencies

sind optionale Felder. Das dependencies gibt die Module an, von denen das Projekt abhängt, und devDependencies gibt die für die Projektentwicklung erforderlichen Module an.

Der Wert zeigt auf ein Objekt. Jedes Mitglied dieses Objekts besteht aus dem Modulnamen und der entsprechenden Versionsanforderung, die das abhängige Modul und seinen Versionsbereich angibt.

Standardmäßig wird kein package.json erstellt. Es wird generiert, wenn wir ein Modul npm install installieren.

npm install express
npm install express --save
npm install express --save-dev

Der obige Code bedeutet, das Express-Modul separat zu installieren.

• Wenn dahinter keine Parameter stehen, bedeutet dies, dass es in dependencies installiert wird.
Der Parameter --save bedeutet, das Modul in die Abhängigkeiten zu schreiben
• --save-dev bedeutet devDependencies das Modul
• --save dependencies zu schreiben.

7.

Das optionale Feld bundledDependencies enthält andere Abhängigkeiten, die beim Veröffentlichen des Pakets gleichzeitig gepackt werden.

8.

Optionales Feld „peerDependencies“, Kompatibilitätsabhängigkeit, wenn Ihr Projekt oder Modul gleichzeitig von einem anderen Modul abhängt, die Version, von der es abhängt, jedoch unterschiedlich ist.

Ihr Projekt hängt beispielsweise 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.

{
  „name“: „chai-wie-versprochen“,
  „peerDependencies“: {
    „chai“: „1.x“
  }
}

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

9.

Das optionale Bin-Feld wird verwendet, um den Speicherort der ausführbaren Datei anzugeben, die jedem internen Befehl entspricht.

Erstellen Sie die Datei /bin/www im Projektstammverzeichnis

Konfigurieren Sie

„bin“

/usr/bin/env node

  „lee-cli“: „./bin/www“
}

npm link fügt den Wertpfad des bin-Attributs im Paket zu einem globalen Link hinzu, erstellt eine Verknüpfungsverbindung und

führt lee-cli in der Befehlszeile aus, um die bin/www-Datei auszuführen. Der Prozess ist:

Im obigen Beispiel erstellt www einen symbolischen Link node_modules/.bin/www . Da das Verzeichnis node_modules/.bin/ zur Laufzeit zur PATH-Variablen des Systems hinzugefügt wird, können diese Skripte beim Ausführen von npm direkt über Befehle ohne Pfad aufgerufen werden.

10. config

Das Konfigurationsfeld wird verwendet, um Werte an Umgebungsvariablen auszugeben

{
  „Name“: „Paket“,
  „config“ : { „port“ : „8080“ },
  "scripts" : { "start" : "node server.js" }
}

Wenn wir es ändern möchten, können wir

npm config set package:port 80

11 verwenden. Das

optionale Feld „engines“ gibt die Plattformversion an, auf der das Modul ausgeführt wird, z. B. eine bestimmte Version von Node oder einen Browser. Sie können auch angeben anwendbare npm Version.

"Motoren" : { 
„Knoten“: 
„>=0,10,3 <0,12“
}

12.

Optionales Feld „Lizenz“, das die Definition der Lizenz angibt, die für den in package.json beschriebenen Code gilt. Unterschiedliche Protokolle haben unterschiedliche Einschränkungen. Teilen Sie den Benutzern mit, welche Berechtigungen sie zur Nutzung Ihres Moduls haben und welche Einschränkungen es bei der Nutzung gibt.

Bitte besuchen Sie: Choosealicense.com/, um eine Lizenz auszuwählen.

Beispiel: MIT: maximale Berechtigung, andere können Ihren Code nach dem Herunterladen ändern, Standardinstallationswert.

13.

Optionales Feld „Autor“, Projektentwickler.

14. Privates

optionales Feld, boolescher Wert, ob privat. Wenn es auf „true“ gesetzt ist, verweigert npm die Veröffentlichung.

Auf diese Weise wird verhindert, dass private Pakete an Außenstehende weitergegeben werden. Wenn Sie ein Paket so umschließen möchten, dass es nur in einer bestimmten Registrierung (z. B. einer internen Registrierung) veröffentlicht wird, können Sie die Beschreibung des PublishConfig-Wörterbuchs unten verwenden, um die Registrierungskonfigurationsparameter zum Zeitpunkt der Veröffentlichung zu überschreiben.

15. Das

optionale Schlüsselwortfeld „Projektschlüsselwörter“ ist ein String-Array. Es hilft Benutzern, das Paket zu finden, wenn sie die NPM-Suche verwenden.

16. Das optionale Feld os

gibt das Betriebssystem an, auf dem das Modul ausgeführt werden kann.

17. style

style gibt den Speicherort der Style-Datei an, wenn sie vom Browser verwendet wird.

18.

Der Ort, an dem der Repository-Paketcode gespeichert wird, kann Git oder SVN sein.

19. Das

optionale Feld „Homepage“ enthält keine URLs mit Protokollpräfixen wie http://.

Versionsproblem:

Version: „1.0.0“

1.0.0:

Die erste Ziffer bedeutet: Inkompatibilität mit altem Code, umfangreiches Update, neue Versionsveröffentlichung;

die zweite Ziffer bedeutet: einige Funktionen wurden hinzugefügt,

die dritte Ziffer

bedeutet: einige Funktionen wurden hinzugefügt, Abwärtskompatibilitätsbit

bedeutet: kleine Patches, Fehlerkorrekturen;

wenn wir das Projekt veröffentlichen, verwenden wir npm + git,

• um npm version patch (Patch-Patch) zu verwenden ; Verwenden Sie zum Ausführen git tag .
• Verwenden Sie npm version minor um die zweite Ziffer der Git-Version zu ändern.
Verwenden Sie die
• npm version major , um die erste Ziffer der Git-Version zu ändern ;

npm-Version [<neue Version> |. premajor |.

Major: Hauptversionsnummer Minor: Nebenversionsnummer Patch: Patchnummer Premajor: vorläufige Hauptversion Prepatch: vorläufige Nebenversion Prerelease: Vorabversion

PS: Hinweis: Wenn ein Fehler gemeldet wird: Git-Arbeitsverzeichnis nicht sauber, bedeutet das, dass Sie Ich brauche git status um jetzt sauber zu sein.

git add .
git commit -m „package.json detaillierte Erklärung“

npm versin monir -m"增加版本号"

git push -u origin master

Wie formuliere ich Regeln?

Als Benutzer können wir in der Datei package.json angeben, wie viele Updates wir für dieses Paket akzeptieren können (vorausgesetzt, wir verlassen uns derzeit auf Version 1.2.4):

• Wenn wir beabsichtigen, nur Updates für die Patch-Version zu akzeptieren (d. h. die letzte Ziffer ändern), können Sie es so schreiben:

  1.2
   1.2.x
   ~1.2.4

• Wenn Sie kleinere Versionsaktualisierungen (Änderungen an zweiter Stelle) akzeptieren, können Sie so schreiben:

  1
  1.x
  ^1.2.4

• Wenn Sie Hauptversionsaktualisierungen akzeptieren können (natürlich auch Nebenversions- und Patch-Versionsänderungen), können Sie so schreiben:

  *x

  Zusammenfassend: Es gibt drei Arten von Versionsänderungen, welche Art von Aktualisierung abhängiger Pakete akzeptiert wird ? Schreiben Sie die Versionsnummer genau auf die vorherige Ziffer.

Versionszyklus und -stufen:

• α-Alpha Die erste Phase dient im Allgemeinen nur internen Tests.
• β-Beta Die zweite Phase hat die meisten Unvollkommenheiten in der Software beseitigt, es können jedoch immer noch Mängel und Lücken vorhanden sein, und wird im Allgemeinen für bestimmte Tests bereitgestellt und verwenden Sie es in der Benutzergruppe
• . Zu diesem Zeitpunkt ist das Produkt ziemlich ausgereift und muss nur an einigen Stellen weiter optimiert werden, bevor es auf den Markt gebracht

werden

2.1.0-beta.1 wird im Allgemeinen von Benutzern wie diesem verwendet. Diese Art von Dingen wird nicht von Insidern und Testern verwendet.

Unterscheiden Sie zwischen der Installation Dependencies und dependencies ?

devDependencies sind für die Entwicklung erforderliche Module, sodass wir sie nach Bedarf während des Entwicklungsprozesses installieren können, um unsere Entwicklungseffizienz zu verbessern, z. B. einige bekannte Bibliotheken von Drittanbietern, webpack , rollUp , less , babel usw. Eine Installation in der Produktionsumgebung ist nicht erforderlich.

Es wird empfohlen, die folgenden Bibliotheken in devDependencies zu installieren:

• Unit
• -Test-Unterstützung (Mocha, Chai);
• Syntaxkonvertierung
• (JSX zu JS, ​​Coffeescript zu JS, Typescript zu JS)
• webpack, gulp, grunt, uglifyJS);
• CSS-Prozessor (postCSS, SCSS, Stylus)
• ;

Abhängigkeitspaket (angeben, aktualisieren, lokal, verwenden, deinstallieren)

das

lokale Abhängigkeitspaket

npm install jquery

Erstellen Sie im aktuellen Verzeichnis ein Verzeichnis node_modules und laden Sie dann das von uns angegebene Paket in dieses Verzeichnis herunter.

2. Um die Installationsversion anzugeben, können Sie nach dem Paketnamen @版本号.

Wenn der Name eines Pakets mit package @ beginnt, handelt es sich um ein Paket mit Gültigkeitsbereich .

npm installiere [email protected]
npm install jquery@">=1.1.0 <2.2.0"

npm install jquery@latest

aktualisiert wurde, ändert sich auch die Versionsnummer in den Abhängigkeiten.

3. Aktualisieren Sie das abhängige Paket

npm update jquery

4. Verwenden Sie das Paket

let jquery = require('jquery');

<script src="/node_modules/jquery/dist/jquery.js">//Dies muss beachtet werden path</script>

6 , Deinstallieren Sie das abhängige Paket

npm uninstall jquery

Semantische Versionierung (semantische Versionierungsregeln)

• https://docs.npmjs.com/about-semantic-versioning

• https://github.com/npm/node-semver

Paket .json-Hinweise

gemäß dem oben Gesagten: Wenn wir npm init werden wir aufgefordert, mehrere Elemente auszufüllen. Einige davon sind optional und andere sind erforderlich. Diese Pflichtfelder müssen alle Felder haben, die ein package.json enthalten muss: name und version . Wenn nicht, kann install nicht ausgeführt werden.

• .

Sie

• die
• oben xxx semantischen Versionsregeln