Yarn: Fügen Sie ein Mittel hinzu, um Paket-Peer-Abhängigkeiten für die Entwicklung / das Testen zu installieren

Erstellt am 27. Okt. 2016  ·  72Kommentare  ·  Quelle: yarnpkg/yarn

Möchten Sie ein _Feature_ anfordern oder einen _bug_ melden?
Merkmal

Wie ist das aktuelle Verhalten?
N / A

Was ist das erwartete Verhalten?
Geben Sie einen CLI-Befehl yarn install --peer dem Peer-Abhängigkeiten installiert werden, die in package.json . Auf diese Weise können beim Entwickeln / Testen Peers wie "react / ng2 / grunt" verwendet werden.

cat-feature help wanted triaged

Hilfreichster Kommentar

+1 Dies ist wichtig für Bibliotheksautoren

Alle 72 Kommentare

@ jpollard-cs Ich beziehe mich nicht auf das Hinzufügen eines Pakets als Peer-Abhängigkeit, sondern auf die Möglichkeit, alle derzeit als Peer-Abhängigkeiten aufgelisteten Pakete zu installieren.
Andernfalls gibt es kein praktikables Mittel zur Entwicklung von Plugins.

npm install
Installiert alle Pakete, die im Abschnitt "package.json-Abhängigkeiten" deklariert sind.

yarn add --peer
Ich habe erwartet, dass alle im Abschnitt package.json peerDependencies deklarierten Pakete installiert werden.

Gibt es eine Möglichkeit, deklarierte Pakete in peerDependencies zu installieren?

Mein Anwendungsfall ist die Entwicklung / Erprobung eines reaktiven nativen Moduls.

Hier ist das NPM-Problem, das sie geschlossen haben: https://github.com/npm/npm/issues/11213

Anscheinend nicht wichtig für NPM-Entwickler.

+1 Dies ist wichtig für Bibliotheksautoren

Ich habe dies bereits zum Thema NPM geschrieben, aber für Garnleute:

Ich habe ein CLI-Programm geschrieben , das die Peer-Abhängigkeiten eines Pakets installiert:

# If you're using npm
npm install -g install-peerdeps

# If you're using yarn
yarn global add install-peerdeps

cd my-project-directory

install-peerdeps <package>[@<version>]

# for example
install-peerdeps @angular/core
# will install all of angular's peerdeps

Wenn Sie irgendwelche Probleme damit haben, öffnen Sie bitte eine Ausgabe auf dem Repo!

@ Nathanhleung , dieses Paket scheint alle Ihre Abhängigkeiten Peer-Abhängigkeiten zu installieren. Darum geht es in diesem Ticket nicht ganz. Hier geht es um die Installation der Peer-Abhängigkeiten Ihres eigenen Pakets.

Ich habe es mit einem Paket , das zu tun, https://www.npmjs.com/package/@team-griffin/install -tafeln Kollegen

@ Nathanhleung du

Hmm ... Wenn man Abhängigkeiten für Entwicklung / Test benötigt, sollte man sie nicht unter devDependencies ? Ich versuche nicht, eine Bombe oder so etwas fallen zu lassen ...

@nikolakanacki Völlig sehen, woher Sie kommen, ich denke, die Seltsamkeit ist, dass es sowohl eine Peer-Abhängigkeit als auch eine Dev-Abhängigkeit sein würde, da Sie Ihre Verbraucher niemals zwingen sollten, Ihre Dev-Abhängigkeiten zu installieren. Ich stimme zu, um die Installation von Peers zu vereinfachen!

@nikolakanacki Wenn Sie ein Paket erstellen, das auf einem anderen Paket basiert, das der Benutzer installiert, möchten Sie es nicht in devDependencies, was zu einem Duplikat dieses Pakets in einer anderen Version führen kann. In einigen Fällen ist dies nicht sinnvoll ...

Anwendungsfall eslint-find-rules

Das Paket sucht nach in ESLint verfügbaren Regeln, die nicht in Ihrer Konfiguration konfiguriert sind.
Damit dies für einen Benutzer sinnvoll ist, muss das installierte ESLint-Paket überprüft werden und nicht eine bestimmte Version, mit der Ihr Paket geliefert wird (oder latest ).
Es handelt sich also um eine Abhängigkeit von peer .

Wenn Sie jetzt einen Beitrag zum Projekt leisten möchten, möchten Sie ESLint in node_modules installieren, damit Sie Ihren Code testen können, ohne einen npm-Link mit einem Dummy-Projekt durchzuführen, das ESLint installiert.

Wenn der Benutzer yarn ausführt, sollte das System keine Peer-Deps installieren und warnen, dass sie fehlen (dies funktioniert).

Also ... eine Flagge, die Garn dazu bringt, Peer-Deps zu installieren, wenn sie nicht bereits installiert sind, würde dieses Problem freundlicherweise lösen.

Interessanter Punkt

  • yarn add <package> --peer installiert es in node_modules und fügt es zu package.json hinzu
  • yarn add <other_package> entfernt danach das installierte Paket aus node_modules

Ich folge derzeit dem yarn install --peer zu installieren, um dependencies , devDependencies und peerDependencies zu installieren, aber das funktioniert genauso gut für mich.

Wenn ich das richtig mache @kyleholzinger / @gaastonsr , peerDependencies im Entwicklungsmodus installieren ( cd -ed in das Repo / Paket, das peerDependencies , frischer Klon, muss auf diesen Peer-Deps entwickelt werden), aber fügen Sie sie dem Zielprojekt hinzu, sobald Sie das Paket mit Peer-Deps installiert haben?

Zur Verdeutlichung: Sie installieren eslint-find-rules was sich darüber beschwert, dass Sie eslint als Abhängigkeit benötigen (es ist ein peerDependency von eslint-find-rules ), und jetzt möchten Sie einen einfachen Weg diese Abhängigkeiten zu den peer hinzuzufügen, an denen Sie arbeiten (aktuelles Projekt, das von eslint-find-rules abhängt)? Etwas wie "Auflösen und Hinzufügen als neue Abhängigkeiten (Ändern von package.json und yarn.lock ), die am besten zu Peer-Abhängigkeiten passen, die meine aktuellen Abhängigkeiten erfordern"?

Wenn dies Ihr Punkt ist, könnte es sehr nützlich sein. Ich dachte, Sie beziehen sich bei der Entwicklung auf die automatische Installation.

Die Funktion könnte mehr als nur zur Vereinfachung eingeführt werden, zum Beispiel: Mehrere Abhängigkeiten können vom gleichen Paket des Peer-Ziels abhängen, erfordern jedoch unterschiedliche Versionen davon. Diese Funktion kann das Beste daraus machen, indem versucht wird, eine einzige Lösung zu finden passendes Ziel (wenn möglich).

Auf jeden Fall etwas zum Nachdenken.

Wenn dies Ihr Punkt ist, könnte es sehr nützlich sein. Ich dachte, Sie beziehen sich bei der Entwicklung auf die automatische Installation.

Das ist was ich suche. PeerDependencies installieren, wenn ich ein Paket entwickle.

Ja genau @nikolakanacki! Ich denke, es gibt eine großartige Gelegenheit für uns, Menschen bei der Verwaltung ihrer Peer-Deps zu helfen.

@gaastonsr muss es dann zu devDependencies hinzufügen - so einfach ist das. Andernfalls ist Ihr Paket für die Entwicklung defekt. Sobald Sie das Projekt geklont und yarn sollte alles installiert sein und Sie sollten in der Lage sein, Tests usw. auszuführen.

Zwei einfache und völlig unabhängige Fragen, die Sie stellen sollten, bevor Sie diese Abhängigkeit in solchen Fällen installieren:

  1. Mein Paket hängt von diesem Paket ab, aber ich erwarte, dass das Zielprojekt es enthält, da mein Paket nur ein Plugin für dieses Paket ist: Geben Sie es in peerDependencies .
  2. Ich habe Tests, die von diesem Paket abhängen, aber es ist aus irgendeinem Grund nicht in meinem dependencies (und sollte dort nicht aufgeführt sein): Geben Sie es in devDependencies .

Mit anderen Worten: Alle Pakete, von denen erwartet wird, dass sie während der Entwicklung vorhanden sind und nicht als direkte Abhängigkeit von dem zu entwickelnden Paket aufgeführt sind, sollten sich in devDependencies . Duplikate sind kein Problem - nirgends in den Dokumenten heißt es, dass Dupes in diesen Fällen nicht erlaubt / empfohlen werden.

@nikolakanacki Wenn wir ein Plugin für ein Paket erstellen, sollten wir von der installierten Paketversion des Benutzers abhängen. Wenn wir es als devDependency hinzufügen, installieren wir unweigerlich eine andere Version und es wird stattdessen verwendet die Version des Benutzers.

Es sei denn, wir haben die Abhängigkeit als * , aber dann sollte Yarn irgendwie deterministisch sein und das vom Benutzer installierte Paket anstelle unseres bevorzugen.

Derzeit ist es nicht so:

@alexilyaev Ich denke, @nikolakanacki bedeutet, es sowohl als PeerDependency als auch als DevDependency zu installieren.

Dies hat das Problem, dass wir beide synchron halten müssen. Für mich funktioniert es vorerst gut, aber ich denke nicht, dass es ideal ist.

@alexilyaev Wenn Sie ein peerDependency deklarieren, deklarieren Sie auch dessen Version. Sofern im Zielprojekt nicht die Version dieser Peer-Abhängigkeit installiert ist, die auch der von Ihnen definierten Version entspricht, meldet yarn / npm einen Fehler (fehlende Peer-Abhängigkeit, so ähnlich).

Trotzdem hat devDependency nichts damit zu tun, es wird installiert, wenn yarn oder npm install im Quellpaket ausgeführt werden (derjenige, der eine Peer-Abhängigkeit deklariert, z : ein Plugin), und es wird nicht einmal konsultiert, wenn das Paket von einem Paket / Projekt eines Drittanbieters (einem Peer) verwendet wird.

Der Punkt ist: Ich sehe nicht, wie das alles relevant ist?

Ich kann den Schmerz sehen, sie synchron zu halten, aber Sie könnten leicht ein bash / javascript / <whatever> -Skript schreiben, das dies als einen Schritt nach der Installation im überprüft package.json .

Der Punkt, den ich versuche, ist, dass wir in keiner Weise die devDependencies Stimmung brechen oder schlimmer noch einführen sollten: "Laufen yarn oder npm install installiert nicht unbedingt alle erforderliche Abhängigkeiten dieses Paketkonzepts.

Auf der anderen Seite hat yarn eine noch strengere Richtlinie eingeführt, die die Pakete löscht, die nicht anders als dependencies oder devDependencies damit Sie nicht ausgeführt werden später in Fragen.

@nikolakanacki Angenommen , mein Plugin akzeptiert ^7.0.0 und der neueste Peer ist 7.9.0 und der Benutzer ist in package.json 7.4.0 .
Wenn ich auch ^7.0.0 in devDependencies , würde Yarn dann nicht (für den Benutzer) sowohl 7.9.0 als auch 7.4.0 installieren?

In diesem Fall verwendet mein Plugin möglicherweise fälschlicherweise das installierte 7.9.0 anstelle von 7.4.0 .

@alexilyaev Ihr Paket verwendet wie jedes andere Paket in jedem anderen Fall immer die höchste verfügbare Version, die den in Ihrem Paket definierten "Semver-Bereich" für diese Peer-Dep erfüllt.

Ich wäre genauer, aber ich verstehe den von Ihnen vorgestellten Fall nicht ganz. Könnten Sie das bitte klarstellen?

~ Es wird Sie warnen, dass Sie eine peerDependency Inkompatibilität haben, Ihr Plugin erwartet ^7.0.0 und Sie haben die Version 7.4.0 . ~ Aktualisiert: ^7.0.0 erfüllt 7.4.0 .

würde Yarn (für den Benutzer) nicht sowohl 7.9.0 als auch 7.4.0 installieren?

Yarn installiert nicht peerDependencies für Sie und installiert nicht die devDependencies Ihres Plugins, sondern nur die Abhängigkeiten in dependencies .

@gaastonsr Sie haben absolut Recht, außer dass ^7.0.0 mit 7.4.0 zufrieden ist.

Peer-Abhängigkeiten werden nie installiert, Entwicklungsabhängigkeiten werden standardmäßig nicht installiert, wenn das Paket nicht das Hauptpaket ist. Der "Endbenutzer" muss definieren, welche Peer-Abhängigkeiten er erfüllen möchte, indem er sie zusammen mit dem Bereich zu den regulären "Abhängigkeiten" des Projekts hinzufügt. Es kann entweder den "Semver-Bereich" erfüllen oder nicht, den Sie in Ihrem Plugin benötigen, und der Benutzer wird darüber informiert.

Semver-Bereiche, erklärt durch npm: https://docs.npmjs.com/misc/semver
Im Zweifelsfall immer überprüfen: http://jubianchi.github.io/semver-check/

@nikolakanacki in der Lage zu sein, Pakete Peerdependencies einfach zu installieren, wäre großartig!

@nikolakanacki Ok, also in der Tat , wenn der Endbenutzer das Paket installiert, devDependencies wird nicht installiert, so dass ein Paket Autor sollte hinzufügen , peerDependencies auf devDependencies als auch.

Dies löst also das lokale Entwicklungsproblem.

Es scheint jedoch, dass viele Projekte die Peer-Abhängigkeit nicht als Entwicklungsabhängigkeit hinzugefügt haben.
Ich denke, wir sollten anfangen, das Wort zu verbreiten und Projekte an Bord zu bringen.
Dies wird unweigerlich zu langen Diskussionen darüber führen, warum es mit npm, aber nicht mit Yarn funktioniert hat, und unabhängig von den Ergebnissen wird es eine Weile dauern, und möglicherweise werden nicht alle Projekte die Änderung vornehmen.

Also ... Ich schlage vor, weiterhin eine Möglichkeit zur Installation von Peer-Abhängigkeiten zu unterstützen, zumindest damit wir nicht mehr install-peerdeps .

Was ist das eigentliche Problem hier? Es scheint nicht komplizierter zu sein, eine Liste von Deps zu installieren, als eine andere Liste von Deps zu installieren. Peer-Abhängigkeiten gibt es seit einigen Jahren. Wie hat das niemanden gestört?

@ Nikolakanacki Lösung macht vollkommen Sinn. Es ist das, was wir für unsere Bibliotheksentwicklung verwenden. Sie müssen devDependencies ordnungsgemäß in der Bibliothek einrichten, um isolierte Tests durchführen zu können (außerhalb eines Host-Projekts, das die erforderlichen peerDependencies liefert), und Sie benötigen peerDependencies für integrierte Tests und um den Host sicherzustellen Das Projekt führt nicht zu redundanten / duplizierten Paketinstallationen, da die verwendeten Bibliotheken dieselben dependencies und _ nicht peerDependencies und devDependencies ordnungsgemäß verwenden.

Es gibt die kleinen Kopfschmerzen, sie synchron zu halten. Aber wie @nikolakanacki betonte, könnte dies leicht durch einige post-install Skripte gemildert werden.

Welche Lösung?

Ich habe die Kommentare schnell genug durchgearbeitet und keine einfache Lösung bemerkt:

Bitte installieren Sie peerDependencies immer als reguläre Abhängigkeiten, wenn es sich um ein Paket der obersten Ebene handelt

Es passt perfekt zu Entwicklungs- / Testfällen und hat keinen Einfluss auf die Installation des Pakets als Abhängigkeit. Ähnlich der Logik, die wir für yarn.lock haben. Es ist keine zusätzliche "Entwicklung" oder ein anderer Modus erforderlich.

Aufgrund anderer Garnfehler im Zusammenhang mit PeerDependencies scheint es in einigen Fällen genau so zu sein, wie es sich verhält.

Sehr einverstanden, wenn Sie 'yarn install' in einem Repo ausführen, sollten alle Peer-Abhängigkeiten installiert werden, die nicht bereits in deps aufgeführt sind. Ich sehe nicht wirklich, wie es sich in dieser Hinsicht von Entwicklungsabhängigkeiten unterscheidet - wenn Sie auf diesem Modul entwickeln, müssen Sie diese Module installieren

Ich schließe dies, da ich kein klares Bild davon bekommen kann, was das Problem ist und welche Lösung vorgeschlagen wird, wenn es welche gibt.

Fühlen Sie sich frei, mit einer Klarstellung wieder zu öffnen oder einen neuen Fehler einzureichen.

@BYK Sind Sie wirklich sicher, dass Sie das Richtige tun, um Probleme mit 55 Daumen hoch und 34 Kommentaren zu schließen, nur weil es Ihnen nicht klar ist?

Ich denke, es ist ganz einfach: Stellen Sie sicher, dass PeerDependencies installiert sind, wenn sie im Top-Level-Paket festgelegt sind .
Oder lassen Sie uns einen anderen Weg sagen: Behandeln Sie PeerDependencies als reguläre Abhängigkeiten, wenn sie im aktuellen Paket festgelegt sind

Das Hinzufügen von Peer-Abhängigkeiten auch als Entwicklungsabhängigkeiten, wie weiter oben in diesem Thread vorgeschlagen, führt zu einer Unterbrechung des Flusstyps: https://github.com/flowtype/flow-typed/issues/379

@andvgal Ich versuche nur, die Probleme

Ich denke, es ist ganz einfach: Stellen Sie sicher, dass PeerDependencies installiert sind, wenn sie im Top-Level-Paket festgelegt sind.
Oder lassen Sie uns einen anderen Weg sagen: Behandeln Sie PeerDependencies als reguläre Abhängigkeiten, wenn sie im aktuellen Paket festgelegt sind

Dies war eine großartige Zusammenfassung, danke. Öffnen Sie das Problem erneut, aber wir müssen sehr sorgfältig über die Auswirkungen der standardmäßigen Installation von PeerDependencies nachdenken, wenn wir uns für diesen Weg entscheiden.

Oder bieten Sie zumindest eine Möglichkeit, die Peer-Abhängigkeiten separat zu installieren, ohne die Datei package.json zu berühren. Wenn Sie add verwenden, um eine Peer-Abhängigkeit zu installieren, wird der Eintrag in der JSON-Datei geändert. Wenn Sie Ihren Semver-Ausdruck anders eingerichtet haben als das, was Garn standardmäßig schreibt, wird er geändert.

Ich denke, die Idee, einen --peer-Schalter zur Installation hinzuzufügen, ist in Ordnung, aber ich möchte sie tatsächlich einzeln installieren können, da ich oft einige dieser Module verknüpfe und zwischen einem Link und tatsächlich hin und her gehe das Modul installiert haben. Mit npm kann ich einfach 'npm i' ausführen'. In Garn sehe ich kein Äquivalent. Insbesondere möchte ich in der Lage sein, eine Datei unter Verwendung der Angaben in package.json zu installieren, ohne die Datei package.json zu ändern.

@jimsugg , ich habe yarn add <package...> -p , um Peer-Abhängigkeiten, die bereits in package.json aufgeführt sind, manuell zu installieren. Dies ist definitiv ein Anti-Pattern. Es scheint, dass Peer-Abhängigkeiten automatisch in Entwicklungsumgebungen installiert werden sollten (wenn es sich tatsächlich um eine Peer-Abhängigkeit handelt, sollte es zumindest Tests geben, für die das Paket erforderlich ist).

Ich habe nach dem gleichen gesucht und mir diesen Bash-Einzeiler ausgedacht, um alle aufgelisteten Peer-Deps zu installieren (erfordert, dass Sie jq installiert haben): yarn add $(jq -r '.peerDependencies|keys|join(" ")' package.json) .

Ich hoffe das hilft jemand anderem.

@ EdwardDrapkin Danke für diese legendäre Idee! Ich habe es erweitert und schließlich ein npm-Skript hinzugefügt, um dies zu tun:

"install:peers": "yarn add -P $(jq -r '.peerDependencies | to_entries | map(\"\\(.key)@\\(.value | tostring)\") | join(\" \")' package.json)",

Behält nur die Versionsspezifikation von peerDependencies bei;) Hier ist nur ein Problem, wenn Sie nicht das latest -Tag verwenden möchten, sondern ein anderes, an dem Sie gerade arbeiten, wie next oder so.

@shousper Hier ist ein Weg ohne die Abhängigkeit von jq :

node -e "const peers = Object.entries(require('./package.json').peerDependencies || {}).map(d => d.join('@')).join(' '); if (peers.length) process.stdout.write('yarn add -P --no-lockfile ' + String(peers));" | sh

Gibt es ein Szenario, in dem Sie keine Peer-Abhängigkeit des Pakets Foo installieren möchten, wenn Sie direkt an Foo ? Mir fällt keiner ein. Wenn Bar erforderlich ist, um Foo , benötigen Sie es, wenn Sie an Foo . Da es sich um eine Peer-Abhängigkeit handelt, kann es sich nicht um eine reguläre Abhängigkeit handeln. Es müsste dann nur installiert werden, wenn direkt am Paket gearbeitet wird, was auch bei Dev-Abhängigkeiten der Fall ist.

Aus diesem Grund halte ich es für sinnvoll, dass Garn PeerDependencies genauso behandelt wie DevDependencies, aber dann auch das tut, was sie jetzt tun, nämlich Warnungen zu generieren. Normalerweise mache ich einfach jede Peer-Abhängigkeit zu einer Devdependenz, so dass einige Duplikate eingespart werden.

Gibt es einen Grund, warum dies ein Problem wäre? Es wäre wahrscheinlich eine bahnbrechende Änderung, also müsste es bis 2.0 warten, aber ansonsten scheint es in Ordnung zu sein.

Ein Problem kann sein, dass Sie eine spezifischere Version für dev installieren möchten als Ihre Peer-Anforderung. In diesem Fall würde ich sagen, dass Sie die Peer-Version für lokale Installationen überschreiben können sollten, indem Sie sie in devDependencies duplizieren. Zum Beispiel

peerDepdency: react@^16.0.0
devDependency: react@~16.1.0

Würde die lokale Installation von "Reagieren" auf ~ 16.1.0 beschränken, aber jede v16-Version als Peer-Abhängigkeit zulassen. Ich bin mir nicht ganz sicher, wo so etwas notwendig wäre, aber es scheint nicht ungültig zu sein.

Ich stimme @bdwain zu , ich verstehe semantisch, was der Unterschied zwischen einer install nicht unterschiedlich verhalten

@bdwain @kyleholzinger Ich bin anderer Meinung, da peerDependencies ausschließlich dazu gedacht sind, die Notwendigkeit einer Abhängigkeit zu informieren und nicht die tatsächliche Aktion zum Installieren der Abhängigkeit anzuweisen.

Dadurch wird sichergestellt, dass das Problem vorübergehender Abhängigkeitsversionen, die auch im Root- / Top-Level-Paket vorhanden sind, nicht stillschweigend (und falsch) verwendet wird. Betrachten Sie babel-core als Beispiel.

Die fehlende Unterstützung hier im Zusammenhang mit Garn ist die Fähigkeit, sowohl als Peer- als auch als Dev-Dep zu definieren,

Das heißt, um mit der Standardinstallationsspezifikation für Peer-Deps Schritt zu halten und eine bessere Entwicklererfahrung zu bieten ... könnte Garn vielleicht eine --include-peers -Option für den Installationsbefehl einführen?

@hulkish Während ich dem Gefühl zustimme, wann wäre ein Beispiel, wenn Sie etwas als Peer-Abhängigkeit deklarieren möchten, aber nicht als Entwickler-Abhängigkeit?

Wenn ich die Verwendung richtig verstehe, insbesondere mit Garn, ist die Liste der Peer-Abhängigkeiten immer eine Teilmenge der Entwicklungsabhängigkeiten. Wenn dies der Fall ist, sollte dies meines Erachtens offiziell anerkannt werden und Sie sollten Peer-Abhängigkeiten nicht als Entwicklungsabhängigkeiten deklarieren müssen.

Der einzige Grund, warum ich das anspreche, ist, dass ich denke, dass das Hinzufügen eines Befehls / einer Option, die etwas hinzufügen würde, da sowohl eine Entwickler- als auch eine Peer-Abhängigkeit die Komplexität des Garns im Allgemeinen erhöhen würde, und ich denke, dass es hier irgendwo eine Lösung gibt, die nett ist und einfach 😄

@ Kyleholzinger

@hulkish Während ich dem Gefühl zustimme, wann wäre ein Beispiel, wenn Sie etwas als Peer-Abhängigkeit deklarieren möchten, aber nicht als Dev-Abhängigkeit?

Wenn Sie es nicht benötigen, damit Ihre Unit-Tests oder Builds ausgeführt werden können. Nach meiner Erfahrung ist dies tatsächlich die einzige Notwendigkeit, sie zunächst an beiden Stellen hinzuzufügen.

Ich denke, die Lösung hier besteht darin, dass Garn eine Option einführt, mit der Peers automatisch installiert werden können. Beachten Sie, dass der Hauptvorteil der Verwendung von PeerDependencies darin besteht, sich ein Bild davon zu machen, wann inkompatible vorübergehende Abhängigkeiten verwendet werden. Der Schlüssel hier ist, das Standardverhalten von Peer-Deps bei der Installation nicht zu brechen.

Ich denke, @hulkish hat über ein Szenario gesprochen, in dem Sie sich auf eine Abhängigkeit einer Abhängigkeit verlassen, um eine Ihrer Peer-Abhängigkeiten zu ziehen. Ich glaube jedoch nicht, dass dies zu Problemen führen würde, da die transitive Abhängigkeit immer noch mit dem durch die Peer-Abhängigkeit angegebenen Bereich übereinstimmen müsste, der ohnehin ein großer Bereich sein muss. Wenn die transitive Abhängigkeit spezifischer wäre als die Peer-Abhängigkeit, hätte dieser Bereich Vorrang und alle Anforderungen wären weiterhin erfüllt.

@hulkish

Wenn Sie es nicht benötigen, damit Ihre Unit-Tests oder Builds ausgeführt werden können

Verstehe das total! Das wirft zwar die Frage auf: Wenn etwas eine Peer-Abhängigkeit ist, Sie es aber nicht benötigen, damit Ihr Unit-Test oder Build ausgeführt werden kann, warum haben Sie es dann als Peer-Abhängigkeit?


Beachten Sie, dass der Hauptvorteil der Verwendung von PeerDependencies darin besteht, sich ein Bild davon zu machen, wann inkompatible vorübergehende Abhängigkeiten verwendet werden

Dem stimme ich voll und ganz zu. Ich denke, Peer-Abhängigkeiten sind derzeit vom Konsumenten des Moduls, das die Abhängigkeit von einer Bibliothek mit Peer-Abhängigkeiten deklariert, erstaunlich. Mein Hauptproblem ist die Entwicklung von Modulen mit Peer-Abhängigkeiten. Entschuldigung, wenn es Verwirrung gab!

Meine Hauptfrage / Vorschlag / Hoffnung, dass es genehmigt wird, um daran zu arbeiten, wäre, wenn Sie yarn install (nicht in Produktion) in einem Modul, das Peer-Abhängigkeiten in seinen eigenen package.json dass sowohl seine Entwicklungsabhängigkeiten als auch seine Peer-Abhängigkeiten installiert werden. Das ist der Hauptunterschied. Derzeit werden nur Dev-Abhängigkeiten installiert, sodass Sie Deps sowohl als Dev-Abhängigkeiten als auch als Peer-Abhängigkeiten deklarieren müssen.


@bdwain @hulkish

Ich denke, @hulkish hat über ein Szenario gesprochen, in dem Sie sich auf eine Abhängigkeit einer Abhängigkeit verlassen, um eine Ihrer Peer-Abhängigkeiten zu ziehen

Ich spreche speziell davon, wenn Sie beim Entwickeln eines Moduls mit Peer-Abhängigkeiten yarn install ausführen und nicht, wenn Sie einem anderen Projekt ein Modul mit Peer-Abhängigkeiten hinzufügen

@bdwain nicht genau, es ist definitiv eine rutschige Sache zu beschreiben. Ich werde versuchen, ein Beispiel zu verwenden:

Anwendungsfall mit Problem

Angenommen, dies ist Ihr Top-Level-Paket:

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

dann dein foo / package.json:

  "dependencies": {
    "react": "^16.0.0"
  }

Gemäß diesem Abhängigkeitsbaum sieht das Verzeichnis node_modules beim Ausführen der Installation von yarn / npm folgendermaßen aus:

node_modules/
  react/ <-- @^15.0.0
  foo/node_modules/react/ <-- @^16.0.0

An diesem Punkt würden Sie nie wissen, dass es ein Problem gibt, es sei denn, Sie (aus welchem ​​Grund auch immer) entscheiden sich freiwillig, die verschachtelte Verzeichnisstruktur von node_modules freiwillig zu überprüfen. Dies ist nicht die Schuld des Paketmanagers - er hat seine Arbeit genau erledigt.

PeerDependencies soll diesen Anwendungsfall lösen, indem sie eher als Validierungsprüfung als als Installationsanweisung behandelt werden.

Anwendungsfall mit PeerDependencies-Lösung

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

dann dein foo / package.json:

  "peetDependencies": {
    "react": "^16.0.0"
  }

Lassen Sie uns zunächst klarstellen, dass an diesem Punkt beide Anwendungsfälle das gleiche Problem haben, dass Reaktionsversionen nicht miteinander kompatibel sind.

Der Unterschied in diesem Anwendungsfall ist; Anstelle dieses Problems besteht stillschweigend. Wenn Sie npm / yarn install ausführen, muss der Paketmanager die Inkompatibilität als Fehler oder Warnung melden.

Hoffe das erklärt es besser.

@ Kyleholzinger

Ich spreche speziell davon, wann Sie bei der Entwicklung eines Moduls mit Peer-Abhängigkeiten eine Garninstallation durchführen und nicht, wenn Sie einem anderen Projekt ein Modul mit Peer-Abhängigkeiten hinzufügen

Ich verstehe. Ich denke, dass das Standardverhalten für Peer-Deps unverändert bleiben sollte. Ich denke jedoch, dass eine einfache Lösung darin besteht, dies über cli und / oder env vars und / oder .yarnrc konfigurierbar zu machen. So etwas wie --install-peers-as-dev

@hulkish

Ich denke jedoch, dass eine einfache Lösung darin besteht, dies über cli und / oder env vars und / oder .yarnrc konfigurierbar zu machen. So etwas wie --install-Peers-as-Dev

Auf jedenfall! Ich persönlich denke, sie sollten nicht sowohl in Dev-Abhängigkeiten als auch in Peer-Abhängigkeiten sein, aber das könnte eine separate Diskussion sein. Ich denke, das Hinzufügen dieser Option wäre ein solider Kompromiss und eine großartige Möglichkeit, das Problem in der Zwischenzeit zu lösen. Ich werde es überprüfen und versuchen, etwas zusammen zu werfen :)

@kyleholzinger Dies ist ein guter Ort, um https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/install.js#L58 zu starten

Außerdem empfehle ich in Ihrem PR, dass Sie beim Weiterleiten von PeerDependencies, die als Entwickler installiert werden sollen, sicherstellen möchten, dass weiterhin Kompatibilitätswarnungen oder -fehler gemeldet werden.

@hulkish Ich verstehe, was Peer-Abhängigkeiten sind. Mein Punkt war, dass Sie sie in der Praxis immer für Entwicklungszwecke installieren müssen, sodass sie zusätzlich zu ihrer Rolle, Warnungen zu geben, wenn Versionen nicht übereinstimmen, als devDependencies behandelt werden sollten.

Wenn ein Paket Foo eine Peer-Abhängigkeit von Bar hat, wäre das einzige Szenario, in dem Bar nicht installiert werden soll, wenn Sie direkt an Foo arbeiten, wenn Ihre Build- und automatisierten Tests keine Bar benötigen. Wenn dies jedoch der Fall wäre, würde dies nur bedeuten, dass Ihre Builds / Tests nicht die Funktionalität ausübten, die in erster Linie die Peer-Abhängigkeit von Bar erforderte, was nicht der übliche Fall sein sollte.

Ich denke nicht wirklich, dass eine Option zum Aktivieren der automatischen Installation von Peer-Abhängigkeiten das Richtige ist, da sie viel häufiger benötigt wird (es sei denn, Sie haben Peers auch als Entwicklungsabhängigkeiten angegeben, was den Punkt zunichte macht). Wenn eine Option häufig benötigt wird, sollte dies die Standardeinstellung sein und stattdessen eine Option zum Deaktivieren vorhanden sein. yarn install sollte in den häufigsten Fällen ohne Optionen funktionieren, und Peer-Abhängigkeiten müssen als Entwicklungsabhängigkeiten behandelt werden. Dies ist der häufigste Fall. Das Hinzufügen eines zusätzlichen Schritts für den durchschnittlichen Benutzer ist nur eine schlechtere Erfahrung.

Das automatische Hinzufügen zu dev und peer hat immer noch das Problem, die Abhängigkeit an zwei Stellen zu duplizieren. IMO ist ein Problem und sollte nicht erforderlich sein.

In jedem Fall müssen diese Warnungen / Fehler gemeldet werden.

Wie ist es möglich, dass wir diese Funktion noch nicht haben? Ich bin neu in der Erstellung von npm-Paketen, aber es sieht so aus, als ob es Teil des Kernworkflows bei der Entwicklung von npm-Paketen ist.

Gleiche @biels! Ich habe tatsächlich total vergessen, dass ich gesagt habe, ich würde daran arbeiten, also habe ich noch nicht begonnen. Ich werde versuchen, daran zu arbeiten, wenn ich kann, damit wir zumindest Leute haben können, die diese Option in ein .yarnrc und setzen Sie müssen sich nicht die ganze Zeit darum kümmern

Ich denke, diese Funktion ist äußerst wichtig.

Ich kann mir viele Anwendungsfälle vorstellen, insbesondere wenn es um Bibliotheksautoren geht.

Angenommen, ich möchte eine Komponentenbibliothek entwickeln, die react und react-dom als peerDependencies (ich möchte nicht, dass sie irgendwann von demjenigen gebündelt werden, der sie verwendet, der sich duplizieren würde diese beiden Bibliotheken und könnte Probleme verursachen, die ich zuvor erlebt habe).

Ich möchte meine Komponentenbibliothek mit den installierten peerDependencies testen, daher möchte ich yarn --include-peerDeps (oder ähnliches) auf CI und auf meinem Computer ausführen, aber wenn jemand yarn auf ihrem eigenen Paket Ich möchte, dass sie ihre eigenen react und react-dom Abhängigkeiten verwenden, um ihre Tests auszuführen (egal wie sie es machen).

Ich denke auch, dass es bereits gerechtfertigt ist, diese Funktion nativ zu machen, da es Module gibt, die genau dies tun und viele Downloads haben. (Das alte Motto "etwas machen, was die Leute wollen" gilt hier IMO)

Ich kann nicht sehen, wie dies eine schlechte Praxis sein könnte, da es explizit durch --include-peerDeps umgeschaltet werden müsste.

Gerne diskutiere ich und helfe bei Bedarf bei der Implementierung.

@lucasfcosta konnte nicht mehr zustimmen! Ich habe heutzutage nicht viel Zeit, um daran zu arbeiten, also habe ich versucht, herumzustöbern, wenn ich kann, aber ich kann die Option scheinbar nicht über die Befehlszeilenoption wahrheitsgetreu finden. Würde aber gerne helfen :)

@lucasfcosta Hier ist meine schlechte Implementierung, wo ich dachte, dass die Option leben könnte, aber ich habe keine Ahnung. Ich habe versucht, dem Muster einiger anderer Befehlszeilenoptionen zu folgen, schien aber nicht zu funktionieren.

Ich verfolge derzeit den Duplizierungsansatz (devDependencies und peerDependencies), würde diese Funktion jedoch sehr lieben, damit ich damit aufhören kann.

Das brauche ich auch. In der Zwischenzeit habe ich eine kleine Knotenaufgabe erledigt

const pkg = require('./package.json');
const entries = Object.entries(pkg.peerDependencies);
const shell = require('shelljs');

let deps = ['yarn add'];
for ([dep, version] of entries) {
    deps[deps.length] = `${dep}@${version}`;
}

deps.push('--peer');
const cmd = deps.join(' ');
console.log('Installing peer deps!\n -----', cmd);
const result = shell.exec(cmd);

if (result.code !== 0) {
    shell.echo('Error: installing peer dependencies');
    shell.exit(1);
}

Cool! Jetzt können wir es einfach in Garn einfügen und eine Flagge oder was auch immer hinzufügen.

Am Do, 4. Oktober 2018, 17:29 Pasquale Mangialavori [email protected]
schrieb:

Das brauche ich auch. In der Zwischenzeit habe ich eine kleine Knotenaufgabe erledigt

`const pkg = require ('./ package.json');
const entry = Object.entries (pkg.peerDependencies);
const shell = require ('shelljs');

let deps = ['Garn hinzufügen'];
für ([dep, version] von Einträgen) {
deps [deps.length] = $ {dep} @ $ {version};
}}

deps.push ('- peer');
const cmd = deps.join ('');
console.log ('Peer deps installieren! n -----', cmd);
const result = shell.exec (cmd);

if (result.code! == 0) {
shell.echo ('Fehler: Installieren von Peer-Abhängigkeiten');
shell.exit (1);
} `

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/1503#issuecomment-427063046 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AE64MGxna2iQ-BFNiC52mIVro8sydPu1ks5uhilsgaJpZM4KiMuo
.

Ich verfolge auch den Duplizierungsansatz, wie

Übrigens, hat jemand eine bessere Lösung, damit wir nicht zweimal ein Paket hinzufügen müssen (devDependencies und peerDependencies)?

Hallo aus der Zukunft. Dies ist immer noch ein Problem für Paket- / Bibliotheksentwickler. Doppelte Deps sollten nicht die Antwort sein.

Ich würde definitiv gerne sehen, dass diese Funktion hinzugefügt wird. Ohne react zu devDependencies meines Pakets hinzuzufügen, kann ich keinen Test für meinen Code ausführen.

Ein Flag für die Installation der Pakete im lokalen peerDependencies -Objekt wäre schön, aber ich sehe auch keinen Nachteil darin, die Installation von _only_ local peerDependencies zum Standardverhalten zu machen. Und semantisch ist es sinnvoll, dass die Peer-Abhängigkeiten vorhanden sein müssen, damit das Paket überall funktioniert. Warum sollte es lokal anders sein?

Meine Meinung zur Verwendung einer Flagge wäre aufgrund ihrer Ausrichtung mit der folgenden
yarn add --peer Befehl.

yarn --peer
# and
yarn install --peer

Zumindest sollte die Flagge eingeführt werden.

Ich frage mich, ob die Verwendung einer separaten test App hier eine gute Lösung ist. Sie können dann alle Ihre peerDependencies als dependencies der test App hinzufügen. Dies scheint Folgendes zu tun:

  • hält peerDependencies von devDependencies in Ihrer Bibliothek fern
  • Sie werden Ihre Bibliothek in gewisser Weise e2e testen ... um sicherzustellen, dass Ihr dist ordnungsgemäß erstellt wird, Sie alle Ihre Komponenten korrekt exportieren und so etwas
  • vermeidet den gelegentlichen Invalid hook call Fehler, wenn Sie vergessen, node_modules aus Ihrem Paket zu entfernen, wenn Sie lokale Abhängigkeiten wie "my-package": "file:/path/to/my-package"

Wenn weitere Informationen für die Leute hilfreich wären, habe ich ein Demo-Repo erstellt, um diesen Ansatz zu modellieren und das Problem zu dokumentieren:
https://github.com/jamstooks/package-peer-dependencies

Im Moment sollten Sie in der Lage sein, npx install-peerdeps <package> auszuführen, und die CLI fragt Sie dann, ob Sie Yarn für die Installation verwenden möchten, wenn Sie eine Garnsperre usw. im Ordner haben. Zumindest hat das gerade bei mir funktioniert.

Weitere Diskussionen von Arcanis ("Installation bei fehlenden Peer-Deps fehlschlagen") und Isaac ("Peer-Deps automatisch installieren") finden Sie hier in diesem NPM-RFC:

https://github.com/npm/rfcs/pull/43

Dieser Blog-Beitrag hat mir bei diesem Problem geholfen: https://dev.to/yvonnickfrin/how-to-handle-peer-dependencies-when-developing-modules-18fa

Ich habe ein verwandtes Problem, denke ich.
Für den minimalen Repro habe ich diese Liste von Abhängigkeiten:

  "dependencies": {
    "prismic-reactjs": "^1.2.0"
  },
  "peerDependencies": {
    "react": "^16.12.0"
  },
  "devDependencies": {
    "react": "^16.12.0",
    "redux": "^4.0.5"
  }

Erläuterung: Mein Paket basiert auf der Anwesenheit von react zur Laufzeit und benötigt es auch zum Testen. redux ist hier für Demozwecke, siehe unten.

Jetzt stützt sich prismic-reactjs auch auf react als Peer-Abhängigkeit.
Was passiert, nachdem yarn --production aufgerufen wurde?

React ist sowohl installiert als auch gehisst
Ich würde erwarten, dass keiner der beiden passiert.

Für die Demozwecke wird hier redux hinzugefügt, das nicht installiert ist, was (glaube ich) beweist, dass die vorübergehende Peer-Abhängigkeit die Ursache des Problems ist.

Repro-Repo: https://github.com/emirotin/yarn-react-repro . Führen Sie test.sh für die schnelle Überprüfung aus.

npm hat diese Funktion jetzt mit v7 ... gibt es einen Grund, dies nicht zum Garn hinzuzufügen?

@sajadghawami Soweit ich weiß, hat @arcanis einige ziemlich große Vorbehalte, dies zu tun:

https://github.com/npm/rfcs/pull/43#issuecomment -520584797

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen