Npm ermöglicht die Verwendung mehrerer Versionen desselben Pakets in einem Projekt. Dies ist eine leistungsstarke Funktion.Vermeidung doppelter Module in Bundles bei Verwendung von npm für Front-End-Projekte
In den meisten Front-End-Projekten würde ich jedoch argumentieren, dass es nicht wünschenswert ist, Abhängigkeiten auf der gleichen Bibliothek in verschiedenen Versionen zu haben.
Abhängigkeiten von derselben Bibliothek in verschiedenen Versionen bedeutet, dass der Endbenutzer die angegebene Bibliothek mehrmals laden muss (als separate Anforderungen oder als Teil eines größeren Pakets).
Wenn jedoch npm verwendet wird, um Abhängigkeiten eines Frontend-Projekts zu verwalten, können Sie sehr schnell mit Abhängigkeiten von derselben Bibliothek in verschiedenen Versionen enden.
Ich denke in den meisten Fällen ist dies unerwünscht und die meiste Zeit sind wir uns der Situation gar nicht bewusst.
Ein einfacher Fall, in dem wir in einer solchen Situation am Ende:
Irgendwann in der Zeit, die Sie react-router und history in Ihrem Projekt installieren:
npm i -S [email protected]
npm i -S [email protected]
Zu dieser Zeit react-router hat eine Abhängigkeit zu [email protected] . Als Ergebnis hat Ihr Projekt als Ganzes nur eine Abhängigkeit von dieser Version von history.
Später entscheiden Sie, auf die neueste Version von react-router zu aktualisieren:
npm i -S [email protected]
Jetzt react-router eine Abhängigkeit von [email protected] hat.
Als Konsequenz hat Ihr Projekt jetzt eine Abhängigkeit von [email protected] und eine transitive Abhängigkeit von [email protected].
Beide Versionen von history sind in Ihrem npm_modules enthalten.
Wenn Sie einen Modulbündler wie Webpack oder Browerify verwenden, erhalten Sie ein Paket, das beide Versionen von history enthält.
Höchstwahrscheinlich bemerken Sie es nicht. Aber wenn Sie das bemerken würden, würden Sie wahrscheinlich Ihre direkte Abhängigkeit auf `history @ 2 'aktualisieren.
Wie können wir mit diesem Problem umgehen?
Wie können wir herausfinden, ob unser Front-End-Projekt in verschiedenen Versionen von derselben Bibliothek abhängig ist?
Wie können wir es vermeiden, mit Bündeln zu enden, die größer sind, als sie sein sollten?
Ich weiß, dass technisch npm/Webpack/Browserify in Abhängigkeiten auf der gleichen Bibliothek in verschiedenen Versionen in einem Paket korrekt sind. Aber ich suche nach einem Weg, um es leicht sichtbar zu machen, dass dies geschieht, so dass der Entwickler Schritte unternehmen kann, um die Abhängigkeiten zu optimieren.
ich neu erstellt auch das Beispiel in diesem Repo: https://github.com/jbandi/npm-package-problems
Ich habe 'find-duplicate-dependencies' in einem nicht-trivialen Projekt versucht und es ist sehr schwierig, alle Ausgaben, die es meldet, zu verstehen. Ich denke, das Hauptproblem ist, dass wir auch über npm verwaltete Dev-Abhängigkeiten haben. Und dort sind doppelte transitive Abhängigkeiten nicht wirklich ein Problem. Es wäre nett, wenn 'find-duplicate-dependencies' nur auf Abhängigkeiten beschränkt werden könnte, ohne dev-Abhängigkeiten zu ignorieren. – jbandi
Es scheint auch, dass 'find-duplicate-dependencies' kein weit verbreitetes Werkzeug ist (und nicht unter aktiver Entwicklung). Ich frage mich, wie andere Projekte mit diesem Problem umgehen ... Warum gibt es keine "state-of-the-art" -Lösung, die in einigen der Webpack-Tutorials erwähnt wird? – jbandi
Ihre Punkte sind alle gültig und ich stimme Ihnen zu. Vor einiger Zeit habe ich mein eigenes Tool geschrieben, um meine Browserify-Pakete zu parsen und zu analysieren. Nachdem ich Ihre Frage gelesen hatte, dachte ich, dass es ein Verdienst sein müsste, 'node_modules' zu analysieren und eine schnelle Suche fand dieses Tool. Wenn nichts anderes, vielleicht ist es ein Ausgangspunkt? Hoffentlich hat es jemand anderes schon getan. – cartant