npm-Peer-Abhängigkeiten für den professionellen Entwickler

In diesem Artikel erkläre ich, was npm-Peer-Abhängigkeiten sind und insbesondere, wann Sie sie verwenden sollten. Peer-Abhängigkeiten werden in der package.json-Datei Ihres Projekts im peerDependencies-Objekt aufgeführt.

Um das Beste aus diesem Artikel herauszuholen, sollten Sie zumindest ein einführendes Verständnis von npm haben.

Inhalt

In diesem Artikel:

1. Wir werden genau vergleichen, wie Peer-Abhängigkeiten mit regulären Abhängigkeiten funktionieren.
2. Wir werden uns einige Beispiele sowohl für Peer-Abhängigkeiten als auch für Abhängigkeiten ansehen.
3. Dann werden wir untersuchen, wie npm mit Versionskonflikten umgeht.
4. Abschließend werden wir, nachdem wir die Grundlagen fest im Griff haben, einen Ansatz entwickeln, um zu entscheiden, wann Peer-Abhängigkeiten angemessen sind.

Das Szenario

Um es real zu halten, nehmen wir an, Sie erstellen eine Angular- oder React-Komponentenbibliothek oder auch nur eine einfache JavaScript-Datei, die einige Funktionen exportiert.

Ihr Projekt basiert auf Paketen aus der npm-Registrierung. Diese Pakete sind die Abhängigkeiten Ihres Projekts.

Sie möchten aus Ihrem Projekt Ihr eigenes npm-Paket erstellen. Sie verwenden also npm pack, um aus Ihrem Projekt ein npm-Paket zu generieren. Möglicherweise entscheiden Sie sich sogar dafür, es in der npm-Registrierung zu veröffentlichen.

Andere Teams könnten Ihre Komponentenbibliothek dann als Paket in der npm-Registrierung finden. Sie können npm install verwenden, um Ihr Paket als Abhängigkeit in ihren eigenen Projekten hinzuzufügen. Wir verwenden Abhängigkeiten und Peer-Abhängigkeiten in package.json, um diesen anderen Projekten mitzuteilen, welche Pakete ebenfalls hinzugefügt werden müssen, damit unsere Komponentenbibliothek funktioniert.

Abhängigkeiten versus Peer-Abhängigkeiten

Auf der grundlegendsten Ebene sehen Sie hier, wie Abhängigkeiten und Peer-Abhängigkeiten funktionieren:

Abhängigkeiten

Abhängigkeiten werden in der package.json-Datei Ihres Projekts in einem Abhängigkeitsobjekt aufgeführt.

Wenn Sie den Abhängigkeiten Ihres Codes ein Paket hinzufügen, sagen Sie:

• Mein Code benötigt dieses Paket, um ausgeführt zu werden.
• Wenn dieses Paket noch nicht in meinem Verzeichnis node_modules vorhanden ist, fügen Sie es automatisch hinzu.
• Fügen Sie außerdem alle Pakete hinzu, die in den Abhängigkeiten dieses Pakets aufgeführt sind. Diese Pakete werden Transitive Abhängigkeiten genannt.

Peer-Abhängigkeiten

Peer-Abhängigkeiten werden in der package.json-Datei Ihres Projekts in einem peerDependencies-Objekt aufgeführt.

Durch das Hinzufügen eines Pakets in den peerDependencies Ihres Codes sagen Sie:

• Mein Code ist mit dieser Version des Pakets kompatibel.
• Wenn dieses Paket bereits in node_modules vorhanden ist, tun Sie nichts.
• Wenn dieses Paket noch nicht im Verzeichnis node_modules vorhanden ist oder es sich um die falsche Version handelt, fügen Sie es nicht hinzu. Zeigen Sie dem Benutzer jedoch eine Warnung an, dass es nicht gefunden wurde.

Abhängigkeiten hinzufügen

Also fügen wir Abhängigkeiten in der Datei package.json unseres npm-Paketordners hinzu. Schauen wir uns genau an, wie wir Pakete als Abhängigkeiten hinzufügen, und einige Beispiele für Paketabhängigkeiten.

Abhängigkeit hinzufügen

Eine Abhängigkeit ist ein npm-Paket, von dem unser Code abhängt, um ausgeführt werden zu können. Einige beliebte Pakete, die als Abhängigkeiten hinzugefügt werden können, sind lodash, D3 und chartjs.

Wir fügen eine reguläre Abhängigkeit wie diese hinzu:

npm install lodash

npm fügt den Paketnamen und die Version zum Abhängigkeitsobjekt in der Datei package.json unseres Projekts hinzu.

"dependencies": {
  "lodash": "^4.17.11"
}

Einige von Ihnen erinnern sich vielleicht an die alten Zeiten, als wir das Flag --save verwenden mussten, um npm dazu zu bringen, die Abhängigkeiten in package.json zu aktualisieren. Zum Glück müssen wir das nicht mehr tun.

Hinzufügen einer Peer-Abhängigkeit

Peer-Abhängigkeiten werden verwendet, um anzugeben, dass unser Projekt mit einer bestimmten Version eines npm-Pakets kompatibel ist. Gute Beispiele sind Angular und React.

Um eine Peer-Abhängigkeit hinzuzufügen, müssen Sie tatsächlich Ihre package.json-Datei manuell ändern. Beispielsweise empfehle ich für Komponentenbibliotheksprojekte, je nachdem, welches Framework Sie verwenden, das Hinzufügen von angular/core oder react als Peer-Abhängigkeit.

Wenn Sie also angeben möchten, dass Ihr Paket für React 18 erstellt wurde, könnten Sie etwa Folgendes einfügen:

"peerDependencies": {
   "react": "^18.0.0",
}

Oder vielleicht möchten Sie sagen, dass Sie Ihre Komponentenbibliothek sowohl mit Angular-Version 17 als auch mit 18 getestet haben, aber nicht mit 19, weil diese noch nicht erhältlich war. Dann könnten Sie Folgendes verwenden:

"peerDependencies": {
   "@angular/core": ">=17.0.0 || <19"
}

About Conflicts

I get a lot of questions about whether a certain npm package should go into dependencies or into peerDependencies. The key to making this decision involves understanding how npm deals with version conflicts.

If you have read my previous articles, you know I like you to be able to do this stuff along with me! So feel free to work along with me for this little npm experiment.

conflict-test Project

To get started let’s create a trivial test project. I am going to name mine:
conflict-test

I created it like this:

md conflict-test
cd conflict-test
npm init -y

I then manually edited the package.json file and added two dependencies:

"dependencies": {
    "todd-a": "^1.0.0",
    "todd-b": "^1.0.0"
}

These todd-a and todd-b packages also have their own dependencies:

todd-a

"dependencies": {
    "lodash": "^4.17.11",
    "todd-child": "^1.0.0"
}

todd-b

"dependencies": {
    "lodash": "^4.17.11",
    "todd-child": "^2.0.0"
}

The thing I want you to notice here is that todd-a and todd-b use the same version of lodash. But, they have a version conflict for todd-child:
todd-a uses todd-child version 1.0.0
todd-b uses todd-child version 2.0.0

Now I know that, like me, you are keenly interested in seeing how npm handles this version conflict. In my main project conflict-test I run npm install. As we would expect, npm magically installs the todd-a and todd-b packages in our node_modules folder. It also adds the packages that they depend on (the transitive dependencies). So after running npm install we take a look at the node_modules folder. It looks like this:

node_modules
├── lodash 4.17.11
├── todd-a 1.0.0
├── todd-b 1.0.0
│   └── node_modules
│       └── todd-child 2.0.0
└── todd-child 1.0.0

The interesting thing about this is that our project has one copy of lodash. But, it has two copies of todd-child! Notice that todd-b gets its own private copy of todd-child 2.0.0.

So here is the rule:

npm deals with version conflicts by adding duplicate private versions of the conflicted package.

An Approach to Peer Dependencies

As we saw from our experiment with npm version conflicts, if you add a package to your dependencies, there is a chance it may end up being duplicated in node_modules.

Sometimes, having two versions of the same package is fine. However, some packages will cause conflicts when there are two different versions of them in the same code base.

For example, assume our component library was created using React v15. We wouldn’t want our package adding another completely different version of react when someone adds it as a dependency to their React v18 application.

The key is:
We don’t want our library adding another version of a package to node-modules when that package could conflict with an existing version and cause problems.

peerDependencies or dependencies?

So this brings us to the main question for our dependencies:

When my package depends on another package, should I put it in dependencies or peerDependencies?

Well, as with most technical questions: It depends.

Peer Dependencies express compatibility. For example, you will want to be specific about which version of Angular or React your library is compatible with.

The Guidelines

Favor using Peer Dependencies when one of the following is true:

• Having multiple copies of a package would cause conflicts
• The dependency is visible in your interface
• You want the developer to decide which version to install

Let’s take the example of angular/core. Obviously, if you are creating an Angular Library, angular/core is going to be a very visible part of your library’s interface. Hence, it belongs in your peerDependencies.

However, maybe your library uses Moment.js internally to process some time related inputs. Moment.js most likely won’t be exposed in the interface of your Angular or React components. Hence, it belongs in your dependencies.

Angular or React as a Dependency

Given that you are going to specify in your documentation that your library is a set of Angular or React Components, you may be asking the question:

Do I even need to specify angular/core as a dependency? If someone is using my library, they will already have an existing Angular project.

Good question!

Yes, we can usually assume that for our Angular or React specific library the Workspace will already have the Angular or React packages available. Hence, technically we wouldn’t need to bother adding them to our list of dependencies.

Wir möchten dem Entwickler jedoch unbedingt mitteilen, mit welchen Angular- oder React-Versionen unsere Bibliothek kompatibel ist. Daher empfehle ich folgende Vorgehensweise:

Fügen Sie mindestens das Angular/Core- oder React-Paket für die kompatible Version zu Ihren PeerDependencies hinzu.

Auf diese Weise wird Entwicklern eine Warnung angezeigt, wenn sie versuchen, Ihre React 18-Komponentenbibliothek in ihrem React 16-Projekt zu verwenden. Machen Sie sich nicht die Mühe, die anderen Angular- oder React-Pakete hinzuzufügen. Sie können davon ausgehen, dass sie, wenn sie über Angular/Core oder React verfügen, über die anderen zugehörigen Bibliotheken verfügen.

Abschließend

Im Zweifelsfall sollten Sie sich wahrscheinlich für die Verwendung von peerDependencies entscheiden. Dadurch können die Benutzer Ihres Pakets selbst entscheiden, welche Pakete sie hinzufügen möchten.

Das obige ist der detaillierte Inhalt vonnpm-Peer-Abhängigkeiten für den professionellen Entwickler. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!