Front-End-Kurs (vue): Einstieg ins Lernen
Heutzutage können Front-End-Entwicklungsstudenten nicht auf npm verzichten. Sein hervorragender Paketversionsverwaltungsmechanismus ist für die gesamte wohlhabende NodeJS -Community sehr nützlich Es hilft, unser Verständnis der Modulentwicklung und verschiedener Front-End-Engineering-Konfigurationen zu vertiefen, um unsere Fehlerbehebung zu beschleunigen (ich glaube, viele Studenten haben mit verschiedenen Abhängigkeitsproblemen zu kämpfen).
Dieser Artikel führt eine detaillierte Analyse des Paketverwaltungsmechanismus von npm aus drei Perspektiven durch: package.json , Versionsverwaltung, Abhängigkeitsinstallation und spezifische Beispiele.
In Node.js ist ein Modul eine Bibliothek oder ein Framework und auch ein Node.js -Projekt. Das Node.js -Projekt folgt einer modularen Architektur. Wenn wir ein Node.js -Projekt erstellen, bedeutet dies, dass dieses Modul eine Beschreibungsdatei haben muss, nämlich package.json . Es ist unsere häufigste Konfigurationsdatei, aber haben Sie die darin enthaltene Konfiguration wirklich im Detail verstanden? Die Konfiguration einer angemessenen package.json Datei bestimmt direkt die Qualität unseres Projekts. Daher analysieren wir zunächst die detaillierte Konfiguration von package.json .
Es gibt viele Attribute in package.json , von denen nur zwei ausgefüllt werden müssen: name und version . Diese beiden Attribute bilden die eindeutige Kennung eines npm Moduls.
name der Modulname. Bei der Benennung müssen Sie einige offizielle Spezifikationen und Empfehlungen befolgen:
Der Paketname wird zu einem Parameter in der Modul url , der Befehlszeile oder einem beliebigen nicht url sicheren Zeichen Beides kann nicht verwendet werden. Sie können validate-npm-package-name verwenden, um zu überprüfen, ob der Paketname zulässig ist.
Semantische Paketnamen können Entwicklern helfen, die benötigten Pakete schneller zu finden und zu vermeiden, dass sie versehentlich das falsche Paket erhalten.
Wenn der Paketname einige Symbole enthält, dürfen die Symbole nach dem Entfernen nicht mit dem vorhandenen Paketnamen wiederholt werden.
Da react-native bereits vorhanden ist, können react.native und reactnative nicht erneut erstellt werden.
Beispiel: Der Benutzername ist conard , der Geltungsbereich ist @conard und das veröffentlichte Paket kann @conard/react sein.
name ist die eindeutige Kennung eines Pakets und darf nicht mit anderen Paketnamen wiederholt werden. Wir können npm view packageName ausführen, um zu sehen, ob das Paket belegt ist, und wir können einige grundlegende Informationen darüber anzeigen.
Wenn der Paketname noch nie verwendet wurde, wird ein 404 Fehler ausgegeben:
Darüber hinaus können Sie auch auf https://www.npmjs.com/ gehen, um detailliertere Paketinformationen zu erhalten.
{
„description“: „Eine UI-Designsprache der Enterprise-Klasse und Implementierung von React-Komponenten“,
"Schlüsselwörter": [
"Ameise",
"Komponente",
„Komponenten“,
"Design",
"Rahmen",
"Frontend",
"reagieren",
„Reaktionskomponente“,
„ui“
]
} description wird verwendet, um Modulbeschreibungsinformationen hinzuzufügen, um anderen das Verständnis Ihres Moduls zu erleichtern.
keywords wird verwendet, um Schlüsselwörter zu Ihrem Modul hinzuzufügen.
Natürlich spielen sie auch eine sehr wichtige Rolle, nämlich das Abrufen von Modulen zu erleichtern. Wenn Sie npm search verwenden, um ein Modul abzurufen, werden description und keywords abgeglichen. Wenn Sie eine gute description und keywords schreiben, wird Ihr Modul immer präziser präsentiert:
Entwickler beschreiben können: author und contributors . author bezieht sich auf den Hauptautor des Pakets, und ein author entspricht einer Person. contributors beziehen sich auf contributors . Der Wert ist ein Array. Die Beschreibung der Person kann eine Zeichenfolge oder die folgende Struktur sein
.
„Name“: „ConardLi“,
„email“: „[email protected]“,
„URL“: „https://github.com/ConardLi“
} {
„homepage“: „http://ant.design/“,
"Bugs": {
„url“: „https://github.com/ant-design/ant-design/issues“
},
„Repository“: {
„Typ“: „git“,
„url“: „https://github.com/ant-design/ant-design“
},
} homepage wird verwendet, um die Homepage dieses Moduls anzugeben.
repository wird verwendet, um das Code-Repository des Moduls anzugeben.
bugs gibt eine Adresse oder eine E-Mail-Adresse an, an die Personen, die Fragen zu Ihrem Modul haben, hier Fragen stellen können.
Unser Projekt kann von einem oder mehreren externen Abhängigkeitspaketen abhängen. Entsprechend der unterschiedlichen Verwendung der Abhängigkeitspakete konfigurieren wir sie unter den folgenden Attributen: dependencies、devDependencies、peerDependencies、bundledDependencies、optionalDependencies .
Bevor wir mehrere Abhängigkeitskonfigurationen einführen, werfen wir zunächst einen Blick auf die Abhängigkeitskonfigurationsregeln. Die angezeigte Abhängigkeitspaketkonfiguration kann wie folgt aussehen:
„Abhängigkeiten“: {
„antd“: „ant-design/ant-design#4.0.0-alpha.8“,
"axios": "^1.2.0",
„test-js“: „Datei:../test“,
„test2-js“: „http://cdn.com/test2-js.tar.gz“,
„core-js“: „^1.1.5“,
} Die Abhängigkeitskonfiguration folgt den folgenden Konfigurationsregeln:
依赖包名称:VERSION VERSION ist eine Versionsnummernkonfiguration, die SemVer Spezifikation folgt. Bei der npm install werden Pakete heruntergeladen, die dem angegebenen Versionsbereich entsprechen.依赖包名称:DWONLOAD_URL DWONLOAD_URL ist eine herunterladbare tarball komprimierte Paketadresse. Wenn das Modul installiert ist, wird diese .tar heruntergeladen und lokal installiert.依赖包名称:LOCAL_PATH LOCAL_PATH ist ein lokaler Abhängigkeitspaketpfad, z. B. file:../pacakges/pkgName . Diese Methode eignet sich zum lokalen Testen eines npm Pakets und sollte nicht online angewendet werden.依赖包名称:GITHUB_URL GITHUB_URL ist die Schreibmethode des username/modulename von github , zum Beispiel: ant-design/ant-design . Sie können tag und commit id auch später angeben.依赖包名称:GIT_URL GIT_URL ist git url unserer üblichen Kloncodebasis, die der folgenden Form folgt:<Protokoll>://[<Benutzer>[:<Passwort>]@]<Hostname>[:<Port>] [: ][/]<path>[#<commit-ish> |. #semver:<semver>]
protocal kann in den folgenden Formen vorliegen:
git://github.com/user/project.git#commit-ishgit+ssh://user@hostname:project.git#commit-ishgit+ssh://user@hostname/project.git#commit-ishgit+http://user@hostname/project/blah.git#commit-ishgit+https://user@hostname/project/blah.git#commit-ishdependencies die Module an, von denen das Projekt abhängt. Hier können sowohl die Entwicklungsumgebung als auch die Produktionsumgebungsabhängigkeitsmodule konfiguriert werden, z. B.
„. Abhängigkeiten": {
"lodash": "^4.17.13",
"moment": "^2.24.0",
} Es gibt einige Pakete in , die Sie möglicherweise nur in der Entwicklungsumgebung verwenden, z. B. eslint zum Überprüfen von Codespezifikationen und jest zum Testen. Wenn Benutzer Ihr Paket verwenden, kann es auch ohne die Installation dieser Abhängigkeiten normal ausgeführt werden wird mehr Zeit und Ressourcen in Anspruch nehmen, daher können Sie diese Abhängigkeiten zu devDependencies hinzufügen. Diese Abhängigkeiten werden weiterhin installiert und verwaltet, wenn Sie npm install lokal durchführen, werden jedoch nicht in der Produktionsumgebung installiert:
„devDependencies“: {
"jest": "^24.3.1",
"eslint": "^6.1.0",
} peerDependencies werden verwendet, um die Version anzugeben, von der das von Ihnen entwickelte Modul abhängt, sowie die Kompatibilität der vom Benutzer installierten abhängigen Paketversion.
Die obige Aussage ist möglicherweise etwas zu abstrakt. Nehmen wir als Beispiel package.json von ant-design ant-design :
„peerDependencies“: {
„reagieren“: „>=16.0.0“,
„react-dom“: „>=16.0.0“
} Wenn Sie ein System entwickeln und ant-design verwenden, müssen Sie sich unbedingt auf React verlassen. Gleichzeitig muss sich ant-design auch auf React verlassen. React Version ist 16.0.0 , und die React Version, auf die Sie sich bei der Entwicklung verlassen, ist 15.x :
Derzeit ist ant-design muss React verwenden und importieren:
import * as React from 'react'; import * as ReactDOM from 'react-dom';
Was Sie zu diesem Zeitpunkt erhalten, ist die Host-Umgebung, also die React Version in Ihrer Umgebung, die einige Probleme verursachen kann. In npm2 bedeutet die Angabe peerDependencies , dass die Hostumgebung gezwungen wird, Versionen von react@>=16.0.0和react-dom@>=16.0.0 zu installieren.
Zukünftig erfordert npm3 keine Zwangsinstallation der von peerDependencies angegebenen Abhängigkeitspakete. Im Gegenteil npm3 prüft nach Abschluss der Installation, ob die Installation korrekt ist, und gibt dem Benutzer eine Warnung aus .
"Abhängigkeiten": {
„reagieren“: „15.6.0“,
„antd“: „^3.22.0“
} Ich verlasse mich beispielsweise auf die neueste Version von antd im Projekt und verlasse mich dann auf die Version 15.6.0 von react . Bei der Installation der Abhängigkeit wird die folgende Warnung angezeigt:
In einigen Szenarien ist das abhängige Paket möglicherweise keine starke Abhängigkeit. Wenn dieses abhängige Paket nicht abgerufen werden kann, möchten Sie, dass npm install weiter ausgeführt wird, ohne dass es zu einem Fehler kommt optionalDependencies . Beachten Sie, dass die Konfiguration in optionalDependencies dependencies daher nur an einer Stelle konfiguriert werden muss.
Wenn auf die in optionalDependencies installierten Abhängigkeiten verwiesen wird, muss natürlich eine Ausnahmebehandlung durchgeführt werden. Andernfalls wird ein Fehler gemeldet, wenn das Modul nicht abgerufen werden kann.
unterscheidet sich vom oben genannten. Der Wert von bundledDependencies ist ein Array. Diese Module werden zusammen gepackt, wenn dieses Paket veröffentlicht wird.
"bundledDependencies": ["package1" , "package2"]
{
„license“: „MIT“
} Das license wird verwendet, um die Open-Source-Vereinbarung der Software anzugeben. Die Open-Source-Vereinbarung beschreibt die Rechte, die andere nach Erhalt Ihres Codes haben, welche Vorgänge sie an Ihrem Code ausführen können und welche Vorgänge verboten sind. Es gibt viele Varianten derselben Vereinbarung. Eine zu lockere Vereinbarung führt dazu, dass der Autor viele Rechte an dem Werk verliert, während eine zu strenge Vereinbarung für Benutzer unpraktisch ist und die Verbreitung des Werks erschwert Open-Source-Autoren müssen sich überlegen, welche Rechte sie behalten und welche Einschränkungen sie lockern wollen.
Softwareverträge können in zwei Kategorien unterteilt werden: Open-Source-Verträge und kommerzielle Verträge, auch Rechtserklärungen und Lizenzverträge genannt. Für die meisten Menschen gibt es für jede Software einen eigenen Text, der vom Software-Autor oder einem spezialisierten Anwalt verfasst wird. Es besteht keine Notwendigkeit, dies selbst zu tun. Die Wahl einer weit verbreiteten Open-Source-Lizenz ist eine gute Wahl.
Im Folgenden sind einige gängige Open-Source-Protokolle aufgeführt:
MIT : Solange Benutzer in ihren Kopien des Projekts einen Urheberrechtshinweis und einen Lizenzhinweis einfügen, können sie mit Ihrem Code machen, was sie wollen, ohne dass Sie hierfür Verantwortung tragen.Apache : Ähnlich wie MIT , enthält aber auch Bedingungen im Zusammenhang mit der Patentlizenzierung, die von Mitwirkenden an Benutzer bereitgestellt werden.GPL : Benutzer, die den Projektcode ändern, müssen ihre relevanten Änderungen veröffentlichen, wenn sie Quellcode oder Binärcode weiterverbreiten.Wenn Sie detailliertere Anforderungen an die Open-Source-Vereinbarung haben, können Sie auf Choosealicense.com/ gehen, um eine detailliertere Beschreibung der Open-Source-Vereinbarung zu erhalten.
{
„main“: „lib/index.js“,
} Das main kann die lib/index.js des Programms angeben, beispielsweise den antd antd angegebenen Moduleintrag: import { notification } from 'antd'; Was eingeführt wird, sind lib/index.js .
Wenn Ihr Modul ein Befehlszeilentool ist, müssen Sie einen Eintrag für das Befehlszeilentool angeben, d. h. die Entsprechung zwischen Ihrem Befehlsnamen und der lokal spezifizierbaren Datei angeben. Bei globaler Installation verwendet npm einen symbolischen Link, um die ausführbare Datei mit /usr/local/bin zu verknüpfen. Bei lokaler Installation wird es mit ./node_modules/.bin/ verknüpft.
{
„bin“: {
„conard“: „./bin/index.js“
}
} Zum Beispiel die obige Konfiguration: Wenn Ihr Paket global installiert ist: npm erstellt einen Softlink namens conard unter /usr/local/bin , der auf "./bin/index.js" . Wenn Sie zu diesem Zeitpunkt conard in der Befehlszeile ausführen, wird die verknüpfte js-Datei aufgerufen.
Ich werde hier nicht zu sehr ins Detail gehen, weitere Inhalte werden in meinen nachfolgenden Artikeln zum Befehlszeilentool ausführlicher erläutert.
{
"Dateien": [
„dist“,
„lib“,
„es“
]
} Das files Attribut wird verwendet, um die Liste der Dateien zu beschreiben, die Sie nach npm publish auf den npm -Server übertragen. Wenn Sie einen Ordner angeben, werden alle Inhalte im Ordner einbezogen. Wir können sehen, dass das heruntergeladene Paket die folgende Verzeichnisstruktur hat:
Darüber hinaus können Sie eine
.npmignoreDatei auch so konfigurieren, dass einige Dateien ausgeschlossen werden, um zu verhindern, dass eine große Anzahl von Junk-Dateien annpmübertragen wird. Die Regeln sind die gleichen wie bei.gitignore..gitignoreDateien können auch als.npmignoreDateien fungieren.
Der man -Befehl ist ein Hilfebefehl unter Linux . Mit dem man -Befehl können Sie Befehlshilfe, Konfigurationsdateihilfe, Programmierhilfe und andere Informationen in Linux anzeigen.
Wenn es sich bei Ihrem node.js -Modul um ein globales Befehlszeilentool handelt, können Sie die vom man -Befehl gesuchte Dokumentadresse über das man -Attribut in package.json angeben.
man -Dateien müssen mit einer Zahl oder, wenn komprimiert, .gz enden. Die Zahl gibt an, in welchem Teil von man die Datei installiert wird. Wenn der Name der man -Datei nicht mit dem Modulnamen beginnt, wird der Modulname während der Installation vorangestellt.
Beispielsweise die folgende Konfiguration:
{
"Mann" : [
„/Users/isaacs/dev/npm/cli/man/man1/npm-access.1“,
„/Users/isaacs/dev/npm/cli/man/man1/npm-audit.1“
]
} Geben Sie man npm-audit in die Befehlszeile ein:
Ein node.js -Modul wird basierend auf CommonJS Modulspezifikation implementiert. In strikter Übereinstimmung mit der CommonJS Spezifikation muss das Modulverzeichnis zusätzlich zur Paketbeschreibungsdatei package.json auch die folgenden Verzeichnisse enthalten:
bin : wo Ausführbare Binärdateien werden gespeichert. Verzeichnislib : Verzeichnis zum Speichern von JS-Codedoc : Verzeichnis zum Speichern von Dokumententest : Verzeichnis zum Speichern von Unit-TestfallcodeIm Modulverzeichnis können Sie sich beim Organisieren oder Benennen möglicherweise nicht strikt an die obige Struktur halten Sie können directories in package.json -Eigenschaften angeben, um anzugeben, wie Ihre Verzeichnisstruktur der oben genannten kanonischen Struktur entspricht. Abgesehen davon gibt es für das directories -Attribut vorerst keine weiteren Anwendungen.
{
"Verzeichnisse": {
„lib“: „src/lib/“,
"bin": "src/bin/",
„man“: „src/man/“,
„doc“: „src/doc/“,
„example“: „src/example/“
}
} Das offizielle Dokument besagt jedoch, dass dieses Attribut derzeit zwar keine wichtige Rolle spielt, in Zukunft jedoch möglicherweise einige Tricks entwickelt werden. Beispielsweise können im Dokument gespeicherte Markdown-Dateien und im Beispiel gespeicherte Beispieldateien auf benutzerfreundliche Weise angezeigt werden.
1.6
"Skripte": {
„test“: „jest --config .jest.js --no-cache“,
„dist“: „antd-tools führen dist aus“,
„compile“: „antd-tools führt die Kompilierung aus“,
„build“: „npm run compile && npm run dist“
}
} scripts werden verwendet, um die Abkürzungen einiger Skriptbefehle zu konfigurieren. Diese Skripte können den gesamten Projektlebenszyklus abdecken und können mit npm run command aufgerufen werden. Wenn es sich um ein npm Schlüsselwort handelt, kann es direkt aufgerufen werden. Die obige Konfiguration gibt beispielsweise die folgenden Befehle an: npm run test , npm run dist , npm run compile , npm run build .
Das config wird zum Konfigurieren der im Skript verwendeten Umgebungsvariablen verwendet. Die folgende Konfiguration kann beispielsweise mit process.env.npm_package_config_port im Skript abgerufen werden.
{
"config" : { "port" : "8080" }
} Wenn Ihr node.js -Modul hauptsächlich zur Installation globaler Befehlszeilentools verwendet wird, ist dieser Wert auf true gesetzt und Benutzer erhalten eine Warnung, wenn sie das Modul lokal installieren. Diese Konfiguration hindert Benutzer nicht an der Installation, fordert sie jedoch auf, eine fehlerhafte Verwendung zu verhindern, die zu Problemen führen kann.
Wenn das private Attribut auf true gesetzt ist, verweigert npm die Veröffentlichung. Dies soll verhindern, dass ein privates Modul versehentlich veröffentlicht wird.
„publishConfig“: {
„registry“: „https://registry.npmjs.org/“
}, detailliertere Konfiguration beim Veröffentlichen des Moduls, Sie können beispielsweise konfigurieren, dass nur ein bestimmtes tag veröffentlicht wird, und die private npm Quelle konfigurieren, in der veröffentlicht werden soll. Eine detailliertere Konfiguration finden Sie unter npm-config
Wenn Sie ein Modul entwickeln, das nur unter dem darwin -System ausgeführt werden kann, müssen Sie sicherstellen, dass windows Benutzer Ihr Modul nicht installieren, um unnötige Fehler zu vermeiden.
Die Verwendung des os -Attributs kann Ihnen dabei helfen, die oben genannten Anforderungen zu erfüllen. Sie können angeben, dass Ihr Modul nur auf bestimmten Systemen installiert werden kann, oder eine schwarze Liste von Systemen angeben, die nicht installiert werden können:
„os“ : [ „darwin“, „linux“ ] "os" : [ "!win32" ]
Ich ordne beispielsweise ein Testmodul einer System-Blacklist zu: "os" : [ "!darwin" ] Wenn ich es unter diesem System installiere, erscheint die folgende Fehlermeldung:
DieIn der Knotenumgebung können Sie mit „process.platform“ das Betriebssystem ermitteln.
ähnelt os . Wir können das cpu Attribut verwenden, um die Installationsumgebung des Benutzers genauer einzuschränken:
„cpu“ : [ „x64“, „ia32“ ] "cpu" : [ "!arm", "!mips" ]
In der Knotenumgebung können Sie Process.arch verwenden, um die CPU-Architektur zu bestimmen.
Der Erfolg von Nodejs ist untrennbar mit dem hervorragenden Abhängigkeitsverwaltungssystem von npm verbunden. Bevor Sie das gesamte Abhängigkeitssystem vorstellen, müssen Sie verstehen, wie npm die Versionen abhängiger Pakete verwaltet. In diesem Kapitel werden die Versionsfreigabespezifikationen von npm包vorgestellt, wie die Versionen verschiedener abhängiger Pakete verwaltet werden und einige Best Practices für Paketversionen.
Sie können npm view package version ausführen, um die neueste Version eines package anzuzeigen.
Führen Sie npm view conard versions aus, um alle veröffentlichten Versionen eines package auf dem npm-Server anzuzeigen.
Führen Sie npm ls aus, um die Versionsinformationen aller Pakete im aktuellen Warehouse-Abhängigkeitsbaum anzuzeigen.
Modulversionen in npm包müssen SemVer Spezifikation folgen – einer leitenden, einheitlichen Versionsnummerndarstellungsregel, die von Github entworfen wurde. Es ist eigentlich die Abkürzung für Semantic Version .
Offizielle Website der SemVer-Spezifikation: https://semver.org/Standardversion
Die Standardversionsnummer SemVer -Spezifikation übernimmt das Format XYZ , wobei X, Y und Z nicht negative Ganzzahlen sind und die Nullen vor den Zahlen aufgefüllt
verboten. X ist die Hauptversionsnummer, Y ist die Nebenversionsnummer und Z ist die Revisionsnummer. Jedes Element muss numerisch inkrementiert werden.
major ): Wenn Sie inkompatible API-Änderungen vornehmen.minor ): Wenn Sie abwärtskompatible Funktionen erstellen. Neuepatch ): Wenn Sie Abwärtskompatibilitätsprobleme vornehmen. Korrektur.Beispiel: 1.9.1 -> 1.10.0 -> 1.11.0
Wenn eine Version größere Änderungen aufweist, nicht stabil ist und möglicherweise nicht die erwarteten Kompatibilitätsanforderungen erfüllt, möchten Sie möglicherweise zuerst eine Vorabversion veröffentlichen.
Die führende Versionsnummer kann am Ende von „Hauptversionsnummer. Nebenversionsnummer. Revisionsnummer“ hinzugefügt werden. Fügen Sie zuerst eine Verbindungsnummer und dann eine Reihe von Bezeichnern und Versionskompilierungsinformationen, getrennt durch Punkte, hinzu.
alpha ):beta ):rc : Release candiateWerfen wir einen Blick auf die historischen Versionen von React :
Es ist ersichtlich, dass die Version strikt gemäß SemVer Spezifikation veröffentlicht wird:
主版本号.次版本号.修订号Die Benennung der Nebenversionsnummer16.8.0 -> 16.8.1 -> 16.8.2 strikt inkrementell16.8.0 -> 16.8.1 -> 16.8.2alpha beta rc. Nach der Änderung bestimmter Funktionen npm Pakets ist es normalerweise erforderlich, eine zu veröffentlichen Neue Version: Unser üblicher Ansatz besteht darin, package.json direkt auf die angegebene Version zu ändern. Wenn der Vorgang falsch ist, kann es leicht zu Verwirrung bei der Versionsnummer kommen. Wir können Befehle verwenden, die Semver Spezifikation entsprechen, um diesen Vorgang abzuschließen:
npm version majornpm version patch : Aktualisieren Sie dienpm version minornpm version major : Aktualisieren Sie die Hauptversionsnummerin der Entwicklung ist für den Betrieb einiger Versionsnummern auf jeden Fall unverzichtbar. Wenn diese Versionsnummern der SemVer -Spezifikation entsprechen, können wir das npm-Paket semver für den Betrieb von Versionen verwenden, um uns zu helfen Vergleichen Sie Versionsgrößen, extrahieren Sie Versionsinformationen und andere Vorgänge.
Npm nutzt dieses Tool auch für die Versionierungsarbeit.
npm install semver
semver.gt('1.2.3', '9.8.7') // false
semver.lt('1.2.3', '9.8.7') // true semver.valid('1.2.3') // '1.2.3'
semver.valid('abc') // null semver.valid(semver.coerce('v2')) // '2.0.0'
semver.valid(semver.coerce('42.6.7.9.3-alpha')) // semver.clean(' =v1.2.3 ') // '1.2.3'
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
semver.minVersion('>=1.0.0') // '1.0.0' Die oben genannten sind die häufigsten Verwendungszwecke von Semver. Weitere Informationen finden Sie in der Semver-Dokumentation: https://github.com/npm/node -semver
Wir sehen oft verschiedene Möglichkeiten, verschiedene Abhängigkeiten in package.json zu schreiben:
„dependencies“: {
"signale": "1.4.0",
"figlet": "*",
„reagieren“: „16.x“,
„Tabelle“: „~5.4.6“,
„yargs“: „^14.0.0“
} Die ersten drei sind leicht zu verstehen:
"signale": "1.4.0" : Feste Versionsnummer"figlet": "*" : Jede Version ( >=0.0.0 )"react": "16.x" : Übereinstimmung Hauptversion ( >=16.0.0 <17.0.0 )"react": "16.3.x" : Hauptversion und Nebenversion abgleichen ( >=16.3.0 <16.4.0 )Werfen wir einen Blick auf die letzten beiden, die Versionsnummer Die Symbole ~ und ^ werden in Anführungszeichen gesetzt:
~ : Wenn bei der Installation von Abhängigkeiten eine neue Version abgerufen wird, installieren Sie die neueste Version von z in xyz . Das heißt, während die Hauptversionsnummer und die Nebenversionsnummer unverändert bleiben, bleibt die neueste Revisionsnummer erhalten.^ : Wenn bei der Installation von Abhängigkeiten eine neue Version abgerufen wird, sind sowohl y als auch z in xyz installiert die neuesten Versionen. Das heißt, während die Hauptversionsnummer unverändert bleibt, behalten Sie die Nebenversionsnummer und die Revisionsnummer als neueste Version bei.Die häufigste Abhängigkeit in der Datei package.json sollte "yargs": "^14.0.0" sein, denn wenn wir das Paket mit npm install package installieren, installiert npm standardmäßig die neueste Version und installiert sie dann im Add ein ^ -Zeichen vor der Versionsnummer.
Beachten Sie, dass es sich um eine instabile Version handelt, wenn die Hauptversionsnummer 0 ist. Die Situation ist anders als oben:
0 : ^0.0.z und ~0.0.z sind beide Da sie als feste Versionen gelten, treten bei der Installation von Abhängigkeiten keine Änderungen auf.0 : ^0.yz verhält sich genauso wie ~0.yz , nur die Revisionsnummer wird als neueste Version beibehalten.2.5Zur Definition der öffentlichen API wird die Versionsnummer 1.0.0 verwendet. Wenn Ihre Software in der offiziellen Umgebung veröffentlicht wird oder über eine stabile API verfügt, können Sie Version 1.0.0 veröffentlichen. Wenn Sie sich also dazu entschließen, eine offizielle Version eines npm-Pakets für die Außenwelt freizugeben, markieren Sie dessen Version als 1.0.0.
In der tatsächlichen Entwicklung treten aufgrund von Inkonsistenzen in verschiedenen Abhängigkeiten häufig seltsame Probleme auf. In einigen Fällen möchten wir nicht, dass Abhängigkeiten aktualisiert werden. Es wird empfohlen, während der Entwicklung package-lock.json zu verwenden.
Das Sperren der Abhängigkeitsversion bedeutet, dass die feste Version jedes Mal installiert wird, wenn wir die Abhängigkeit installieren, es sei denn, wir führen Aktualisierungen manuell durch. Stellen Sie sicher, dass das gesamte Team Abhängigkeiten mit konsistenten Versionsnummern verwendet.
Bei jeder Installation einer festen Version ist es nicht erforderlich, den Versionsbereich der Abhängigkeiten zu berechnen, was in den meisten Szenarien die Installationszeit der Abhängigkeiten erheblich verkürzen kann.
Stellen Sie bei Verwendung von package-lock.json sicher, dass die npm-Version über 5.6 liegt, da zwischen 5.0 und 5.6 die Verarbeitungslogik von package-lock.json mehrmals aktualisiert wurde und sich die Nachverarbeitungslogik von Version 5.6 allmählich stabilisierte.
Wir werden die detaillierte Struktur von package-lock.json in späteren Kapiteln analysieren.
Unser Zweck der
Obwohl wir in tatsächlichen Entwicklungsszenarien nicht jedes Mal eine neue Version installieren müssen, müssen wir die Abhängigkeitsversionen dennoch regelmäßig aktualisieren, damit wir von den Problembehebungen, Leistungsverbesserungen und neuen Funktionsaktualisierungen profitieren können, die durch die Aktualisierung der Abhängigkeitspakete entstehen.
Die Verwendung von npm outdated kann uns dabei helfen, die Abhängigkeiten aufzulisten, die nicht auf die neueste Version aktualisiert wurden:
und npm update ausführen.
1.0.0 .主版本号.次版本号.修订号alpha、beta、rc Veröffentlichung einer Hauptversion oder bei großen Versionsänderungennpm -Pakete handelt. Es wird empfohlen, das Versionspräfix ~ zu ändern Die Abhängigkeiten des Hauptprojekts müssen jedes Mal aktualisiert werden, wenn die Unterabhängigkeiten aktualisiert werden, was sehr umständlich ist. Wenn die Unterabhängigkeiten vollständig vertrauenswürdig sind, öffnen Sie ^ jedes Mal direkt auf die neueste Version.docker Linie und Unterabhängigkeiten werden noch lokal entwickelt und aktualisiert. Bevor die docker Version veröffentlicht wird, müssen alle Abhängigkeitsversionen gesperrt werden, um sicherzustellen, dass nach der Veröffentlichung der lokalen Unterabhängigkeiten keine Probleme auftreten freigegeben.npm Version über 5.6 liegt und stellen Sie sicher, dass die Datei package-lock.json standardmäßig aktiviert ist.npm inatall vom Initialisierungsmitglied ausgeführt wurde, wird package-lock.json an das Remote-Warehouse übermittelt. Senden Sie node_modules nicht direkt an das Remote-Repository.npm update aus, um Abhängigkeiten zu aktualisieren, und übermitteln Sie die lock , um sicherzustellen, dass andere Mitglieder ihre Abhängigkeiten gleichzeitig aktualisieren. Ändern Sie die lock nicht manuell.package.json -Datei und führen Sie npm installlocknpm install package@version direkt aus (durch das Ändern von package.json werden die Abhängigkeiten nicht heruntergestuft).
npm install wird wahrscheinlich die oben genannten Prozesse durchlaufen. In diesem Kapitel werden die Implementierungsdetails, die Entwicklung und der Grund für jeden Prozess erläutert.
Wir alle wissen, dass nach der Ausführung von npm install abhängige Pakete in node_modules installiert werden. Schauen wir uns den spezifischen Mechanismus genauer an, mit dem npm abhängige Pakete in node_modules installiert.
In den frühen Versionen von npm war der Umgang mit Abhängigkeiten npm einfach und grob. Es installierte Abhängigkeiten auf rekursive Weise und streng nach der package.json -Struktur und der package.json -Struktur der node_modules . Bis es untergeordnete Pakete gibt, die nicht mehr von anderen Modulen abhängen.
Beispielsweise hängt unser Modul my-app jetzt von zwei Modulen ab: buffer ignore :
{
„name“: „meine-app“,
"Abhängigkeiten": {
"buffer": "^5.4.3",
„ignorieren“: „^5.1.4“,
}
} ignore ist ein reines JS Modul, das nicht von anderen Modulen abhängt, und buffer hängt von den folgenden zwei Modulen ab: base64-js und ieee754 .
{
„Name“: „Puffer“,
"Abhängigkeiten": {
„base64-js“: „^1.0.2“,
„ieee754“: „^1.1.4“
}
} Nach der Ausführung npm install erhält man dann die Modulverzeichnisstruktur in node_modules wie folgt:
Die Vorteile dieses Ansatzes liegen auf der Hand. Die Struktur von node_modules entspricht eins zu eins der Struktur von package.json , die hierarchische Struktur ist offensichtlich und die Verzeichnisstruktur jeder Installation ist garantiert gleich.
Stellen Sie sich jedoch vor, wenn Sie von vielen Modulen abhängig sind, werden Ihre node_modules sehr groß und die Verschachtelungsebene sehr tief sein:
Windows -Systemen beträgt die maximale Dateipfadlänge 260 Zeichen und eine zu tiefe Verschachtelungsebene kann zu unvorhersehbaren Problemen führen.Um die oben genannten Probleme zu lösen, hat NPM in Version 3.x ein großes Update durchgeführt. Es ändert die frühe verschachtelte Struktur in eine flache Struktur:
node_modules installiert, unabhängig davon, ob es sich um eine direkte Abhängigkeit oder eine Unterabhängigkeit handelt.Immer noch mit der obigen Abhängigkeitsstruktur erhalten wir nach der Ausführung von npm install die folgende Verzeichnisstruktur:
Zu diesem Zeitpunkt verlassen wir uns auf die [email protected] im Modul:
{{
"Name": "my-App",
"Abhängigkeiten": {
"Puffer": "^5.4.3",
"Ignorieren": "^5.1.4",
"Base64-JS": "1.0.1",
}
} node_modules , überspringen Sie die Versionsbereich des neuen Moduls, wenn sie nicht übereinstimmt.Zu diesem Zeitpunkt erhalten wir die folgende Verzeichnisstruktur, nachdem wir npm install ausgeführt haben:
Wenn wir auf ein Modul im Projektcode verweisen, lautet der Modulsuchprozess wie folgt:
node_modulesnode_modules[email protected] buffer2@^5.4.3
node_modules wird durchsucht.
Daher löst npm 3.x -Version das Problem der Modul -Redundanz der alten Version nicht vollständig und kann sogar neue Probleme mit sich bringen.
Stellen Sie sich vor, Ihre App hängt nicht von der Version [email protected] ab, aber Sie sind auch von buffer und buffer2 angewiesen, die von verschiedenen base64-js Versionen abhängen. Da bei der Ausführung npm install die Abhängigkeiten in package.json in der Reihenfolge analysiert werden, wird die Reihenfolge, in der buffer und buffer2 in package.json platziert werden. JSON.JSON bestimmt die Abhängigkeitsstruktur von node_modules :
Abhängig von buffer2 zuerst abhängig:
Abhängig von buffer zuerst:
Um den Entwicklern zu ermöglichen, die neuesten Abhängigkeitspakete unter der Prämisse der Sicherheit zu verwenden, sperren wir die große Version in package.json normalerweise nur, was bedeutet, dass nach der Nebenversion einiger Abhängigkeitspakete die Abhängigkeitsstruktur aktualisiert wurde Auch geändert werden.
Um das Unsicherheitsproblem der npm install zu lösen, wurde die Datei package-lock.json in npm 5.x Version hinzugefügt, und die Installationsmethode folgt auch der flachen Methode von npm 3.x
Die Funktion von package-lock.json package-lock.json npm install , die node_modules zu sperren. .
Zum Beispiel haben wir die folgende Abhängigkeitsstruktur:
{
"Name": "my-App",
"Abhängigkeiten": {
"Puffer": "^5.4.3",
"Ignorieren": "^5.1.4",
"Base64-JS": "1.0.1",
}
} Die nach der Ausführung npm install generierte package-lock.json lautet wie folgt:
{{
"Name": "my-App",
„Version“: „1.0.0“,
"Abhängigkeiten": {
"Base64-JS": {
"Version": "1.0.1",
"gelöst": "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz",
"Integrität": "SHA1-ASBRSZT7XZE47TUTDW3I/NP+PAG ="
},
"Puffer": {{
"Version": "5.4.3",
"gelöst": "https://registry.npmjs.org/buffer/-/buffer-5.3.3.tgz",
"Integrität": "SHA512-ZVJ65TKFEIT3I6AJ5BIVJDZJJJQQGS4O/SNOEZG1F1KYAP9NU2JCUDPWZRSJTHMMZG0H7BZKN4RNQPIMHUX2A ==",
"erfordert": {
"Base64-Js": "^1.0.2",
"IEEE754": "^1.1.4"
},
"Abhängigkeiten": {
"Base64-JS": {
"Version": "1.3.1",
"gelöst": "https://registry.npmjs.org/base64-js/-/base64-js-1.3.tgz",
"Integrität": "SHA512-MLQ4I2QO1YTVGWWMCNGKO // JXAQUEZVWEKTJGQFM4JIK0KU+YTMFPLL8J+N5MSPOFJHWOAG+9YHBWWAHM36G =="
}
}
},
"IEEE754": {
"Version": "1.1.13",
"gelöst": "https://registry.npmjs.org/ieee754/-/ieee754-1.1.13.tgz",
"Integrität": "SHA512-4VF7I2LYV/HAWERSO3XMLMKP5EZ83I+/CDLUXI/IGTS/O1SEJBNHTTNXZMRZFVOUQJ7LZJQHKETVPGSFDLWZTG =="
},
"Ignorieren": {
"Version": "5.1.4",
"gelöst": "https://registry.npmjs.org/ignore/-/ignore-5.1.4.tgz",
"Integrität": "SHA512-MZBUSAHKTW1U7JPKKJY7LCARD1FU5W2RLDXLM4KDKAYUCWZIMJKPLUF9CM1ALEWYJGUPDQEWLAM18Y6AU69A8A =="
}
}
} Schauen wir uns die obige Struktur genauer an:
Die beiden äußersten Attribute name und version sind mit name und version in package.json übereinstimmen und werden verwendet, um den aktuellen Paketnamen und die aktuelle Version zu beschreiben.
dependencies sind ein key , das der Paketstruktur node_modules
resolvedversion node_modulesintegrity : hash Wert, basierend auf der Subresource Integrity um zu überprüfen, ob das installierte Softwarepaket geändert oder ungültigrequires dependencies package.json .dependencies : Die Struktur ist die gleiche wie die äußere dependencies und speichert die Abhängigkeitspakete, die in den unterabhängigen node_modules installiert sind.Beachten Sie hier, dass nicht alle Unterabhängigkeiten das Attribut dependencies haben node_modules
Überprüfen Sie beispielsweise die obigen Abhängigkeiten:
Die [email protected] , auf die wir uns in my-app -Konflikten mit base64-js@^1.0.2 node_modules , müssen wir [email protected] in buffer verlassen buffer , das dem dependencies von buffer in package-lock.json entspricht. Dies entspricht auch dem flachen Ansatz von npm zu Abhängigkeiten.
Daher befinden sich nach der obigen Analyse package-lock.json package-lock.json node_modules -Verzeichnisstruktur in eins zu eins. erzeugt durch jede Installation gleich.
Darüber hinaus kann die Verwendung von package-lock.json im Projekt die Abhängigkeitsinstallationszeit erheblich beschleunigen.
Wir verwenden den lock npm i --timing=true --loglevel=verbose lock den vollständigen Prozess der npm install zu sehen. Reinigen Sie den npm -Cache vor dem Vergleich.
Ohne lock -Datei zu verwenden:
lock verwenden:
Es ist ersichtlich, dass die spezifische Version und der Download-Link jedes Pakets in package-lock.json zwischengespeichert wurden. große Anzahl von Netzwerkanfragen.
zur Entwicklung von Systemanwendungen wird empfohlen, die Datei package-lock.json an das Code-Versions-Repository zu senden, um sicherzustellen, dass die von allen Teamentwicklern und CI Links installierten Abhängigkeitsversionen bei der Ausführung npm install konsistent sind.
Wenn Sie ein npm -Paket entwickeln semver muss Ihr npm -Paket aufgrund des oben erwähnten flachen Installationsmechanismus abhängig sein Innerhalb des Geltungsbereichs, was zu unnötige Redundanz führt. Daher sollten wir die Datei package-lock.json nicht veröffentlichen ( npm veröffentlichen package-lock.json -Datei standardmäßig nicht).
Nach dem Ausführen des Befehls npm install oder npm update zum Herunterladen von Abhängigkeiten. Zusätzlich zur Installation des Abhängigkeitspakets im Verzeichnis node_modules wird eine Kopie auch im lokalen Cache -Verzeichnis zwischengespeichert.
Mac .npm/_cacache Linux über npm config get cache
In diesem Verzeichnis gibt es tar Verzeichnisse: content-v2 content-v2 und index-v5 tar index-v5 hash
Wenn NPM die Installation ausführt, kann es einen eindeutigen key generieren, der dem Cache-Datensatz im Verzeichnis index-v5 basierend auf integrity、version、name in package-lock.json entspricht, wodurch hash des tar Pakets gefunden wird. und dann auf der Suche nach hash tar
Wir können ein Paket finden, um im Cache-Verzeichnis zu suchen und zu testen und den Paketpfad in index-v5 :
GREP "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1 zu durchsuchen. TGZ "-R Index -V5
Dann format wir den JSON:
{
"Key": "Pacote: Version-Manifest: https: //registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz: SHA1-ASBRSZT7XZE47TUTDW3I/NP+PAG =",
"Integrität": "SHA512-C2EKHXWXVLSBRUCJTRS3XFHV7MF/Y9KLMKDXPTE8YEVCOH5H8AE69Y+/LP+AHPW91CRNZGO78ELOK2E6APJFIQ ==",
"Zeit": 1575554308857,
"Größe": 1,,
"Metadaten": {{
"ID": "[email protected]",
"Manifest": {
"Name": "Base64-JS",
"Version": "1.0.1",
"Motoren": {{
"Knoten": "> = 0,4"
},
"Abhängigkeiten": {},
"OptionalleDePendenzen": {},
"devDependencies": {{
"Standard": "^5.2.2",
"Band": "4.x"
},
"BundleTependenzen": Falsch,
"PeerDependenzen": {},
"veraltet": falsch,
"_resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz",
"_integrity": "SHA1-ASBRSZT7XZE47TUTDW3I/NP+PAG =",
"_shasum": "6926d1b194fbc737b8eed513756de2fcda7ea408",
"_shrinkwrap": null,
"Bin": null,
"_id": "[email protected]"
},
"Typ": "Finalized-Manifest"
}
} Das obige _shasum -Attribut 6926d1b194fbc737b8eed513756de2fcda7ea408 ist hash des tar -Pakets, und die ersten Ziffern 6926 hash sind die ersten beiden Stufen von Cached -Verzeichnissen.
Die obige Caching -Strategie startet mit der NPM V5 -Version. }.
npm bietet mehrere Befehle zum Verwalten von Cache -Daten:
npm cache add : Die offizielle Erklärung ist, dass dieser Befehl hauptsächlich von npm intern verwendet wird. Er kann jedoch auch verwendet werden, um einem angegebenen Paket manuell einen Cache hinzuzufügen.npm cache clean --force Löschen Sie alle Daten im Cache -Verzeichnis.npm cache verify : Überprüfen Sie die Gültigkeit und Integrität von zwischengespeicherten Daten und säubern Sie Junk -Daten.Basierend auf zwischengespeicherten Daten liefert NPM Offline-Installationsmodi, die wie folgt sind:
--prefer-offline : Verwenden Sie zuerst zwischengespeicherte Daten.--prefer-online : Priorisieren Sie die Verwendung von Netzwerkdaten.--offline : Fordern Sie das Netzwerk nicht an und verwenden Sie die zwischengespeicherten Daten direkt.Wir haben die Datei -Integrität oben erwähnt. Was ist also die Überprüfung der Dateiintegrität?
tarball shasum Herunterladen des Abhängigkeitspakets können wir hash von npm npm info das Abhängigkeitspaket berechneten hash -Wert normalerweise erhalten.
Nachdem der Benutzer das Abhängigkeitspaket lokal heruntergeladen hat, muss er sicherstellen, dass während des Download -Vorgangs keine hash aufgetreten hash . Stellen Sie sicher, dass die heruntergeladene Abhängigkeit abgeschlossen ist.
Nachdem der Gesamtprozess abgeschlossen ist, fassen wir den oben genannten Prozess zusammen:
Überprüfen Sie die .npmrc Datei: Die Priorität ist: Projekt-Level .npmrc Datei> Benutzer-Level .npmrc Datei> Global-Level .npmrc Datei> NPM integriert. .npmrc -Datei
Überprüfen Sie, ob im Projekt eine lock vorhanden ist.
Keine lock :
npm Remote-Lagerhauspackage.json . node_modules .node_modules des aktuellen Moduls.npm kann das Download-Paket von Remote Warehousenpm -Cache-Verzeichnisnode_modules gemäß der Abhängigkeitsstruktur .node_modulesnode_moduleslocklock
package.json package-lock.json .
Der obige Prozess beschreibt kurz den allgemeinen Prozess der npm install package --timing=true --loglevel=verbose npm install . Installationsprozess und Details eines bestimmten Pakets.
yarn wurde 2016 veröffentlicht. Zu diesem Zeitpunkt befand sich npm noch in V3 package-lock.json Zeit. von Entwicklern. Zu diesem Zeitpunkt wird yarn geboren:
Die oben genannten sind die Vorteile des yarn auf der offiziellen Website, die zu dieser Zeit noch sehr attraktiv waren. npm realisierte natürlich seine eigenen Probleme und yarn viele Optimierungen in den nachfolgenden Optimierungen ( lock , Cache, Standard -S ...) mehr oder weniger den Schatten des yarn . Design ist immer noch sehr gut.
von
yarn yarn.lock npm v3 um yarn.lock zu verwalten.
Ist eine autogenerische Datei. # Garn Lockfile V1 [email protected]: Version "1.0.1" behoben "https://registry.yarnpkg.com/base64-js/-/base64-js-1.0.1.tgz#6926d1b194fbc737b8eed513756de2fcda7ea408" Integrität SHA1-ASBRSZT7XZE47TUTDW3I/NP+PAG = Base64-js@^1.0.2: Version "1.3.1" behoben "https://registry.yarnpkg.com/base64-js/-/base64-js-1.3.1.tgz#58ece8cb75ddd07e71ed08c736abc5fac4dbf8df1" Integrität SHA512-MLQ4I2QO1YTVGWFWMCNGKO // JXAQUEZVWEKTJGQFM4JIK0KU+YTMFPLL8J+N5MSPOFJHWOAG+9YHB7BWAHM36G == buffer@^5.4.3: Version "5.4.3" Aufgelöst "https://registry.yarnpkg.com/buffer/-/buffer-5.3.3.tgz#3fbc9c69eb713d323e3fc1a895eeeeee0c0c072115" Integrität SHA512-ZVJ65TKFEIT3I6AJ5BIVJDZJQQGS4O/SNOEZG1F1KYKYAP9NU2JCUDPWZRSJTHMMZG0H7BZKN4RNQPIMHUXWX2A == Abhängigkeiten: Base64-JS "^1.0.2" IEEE754 "^1.1.4" IEEE754@^1.1.4: Version "1.1.13" behoben "https://registry.yarnpkg.com/ieee754/- Integrität SHA512-4VF7I2LYV/HAWERSO3XMLMKP5EZ83I+/CDLUXI/IGTS/O1SEJBNHTTNXZMRZFVOUQJ7LZJQHKETVPGSFDLWZTG == ignore@^5.1.4: Version "5.1.4" behoben "https://registry.yarnpkg.com/ignore/-/ignore-5.1.4tgz#84b7b3dbe64552b6ef0eca99f6743dbec6d97Adf" Integrität SHA512-MZBUSAHKTW1U7JPKKJY7LCARD1FU5W2RLDXLM4KDKAYUCWZIMJKPLUF9CM1ALEWYJGUPDQEWLAM18Y6AU69A8A ==Sehen
package-lock.json
yarn.lock json package-lock.jsonyarn.lock Die Versionsnummer yarn.lock -Neutron ist nicht festgelegt, was bedeutet, dass yarn.lock allein node_modules nicht bestimmen kann und mit der Datei package.json koordiniert werden muss. Und package-lock.json benötigt nur eine Datei, um zu bestimmen.Die Caching -Strategie von yarn sieht dem vor npm v5 sehr ähnlich. Verwenden Sie das Befehlsgarn yarn cache dir um das Verzeichnis von zwischengespeicherten Daten anzuzeigen:
Standardmäßig verwendet das
yarndenprefer-online, was bedeutet, dass Netzwerkdaten zuerst verwendet werden.
Ich hoffe, dass Sie nach dem Lesen dieses Artikels wie folgt helfen werden:
npmpacakge.json zu erhalten.npm npm install package-lock.json