Was ist das erwartete Verhalten?
Das pdfjs-dist-Projekt sollte Webpack nicht als peerDependency enthalten, da es beim Laden der Skripte aus dem Build-Verzeichnis wirklich ohne es funktionieren kann.
Was schief gelaufen ist?
Ich verwende PDFJS in einer Komponente, um ein PDF mit Angular 6 zu visualisieren. Kein Einbinden von Webpack in mein Projekt (ich brauche es überhaupt nicht), mache jedes Mal ein peerDependency-Warn-Popup, wenn ich einen npm-Befehl ausführe oder jedes Mal, wenn jemand meine Komponente installiert .
Genau. webpack
als "peerDependency"
in einem verteilbaren Paket wie diesem zu haben, ist schlichtweg falsch und sollte entfernt werden.
Die Peer-Abhängigkeit wurde in #9249 wegen worker-loader
hinzugefügt. Könnten Sie etwas erläutern, warum es falsch ist, es in unserem Repository zu haben? Ich bin damit einverstanden, es zu entfernen, wenn es sicher ist, dass die Dinge nicht kaputt gehen.
Hallo @timvandermeij. Danke für deine Antwort!
webpack
ist ein Build-Tool und als solches normalerweise nur als "devDependency"
sinnvoll - oder sonst auf die Build-Pipeline der Bibliothek beschränkt. Wenn Sie es als "peerDependency"
einschließen, müssen Benutzer es entweder lokal installieren (auch wenn sie es möglicherweise nicht benötigen / es nicht interessiert) oder die Warnung ignorieren, die jedes Mal auf npm install
.
Ich bin mit worker-loader
nicht vertraut, also nimm meine Kommentare mit einer Prise Salz. Aber wenn es wie jeder andere webpack
Loader ist, werden sie normalerweise nur als Build-Konfigurationsschritt benötigt und sonst nichts. Außerdem macht es wenig Sinn in einem Kontext, in dem die Bibliothek außerhalb des Webs verwendet werden soll (wie Node).
Funktioniert pdf.js
in einigen Fällen als eine Art webpack
Plugin? Wenn es _ist_, _könnte_ es sinnvoll sein, sowohl den Loader als auch webpack
als Abhängigkeit einzuschließen. Aber selbst dann würde ich argumentieren, dass diese Art von Unterstützung in ein eigenes Repository/Modul extrahiert werden sollte.
Ich habe mir die Freiheit genommen, das Repo zu forken und alles, was mit webpack
tun hat, herauszunehmen. Bei mir funktioniert es in meiner Node-Anwendung immer noch absolut einwandfrei.
Gibt es einen Plan, Webpack als Abhängigkeit zu entfernen? @nfantone hattest du vor, eine PR einzureichen?
@mishawakerman Ich habe nie wirklich eine "offizielle" Antwort auf dieses Problem erhalten - und ich weiß immer noch nicht, warum webpack
als Abhängigkeit aufgeführt ist. Meine (begrenzte) Intuition sagt mir, dass dies Teil eines größeren Problems ist, bei dem pdf.js
an einen Teil seiner Implementierung gekoppelt ist, der indirekt von webpack
abhängt und in irgendeiner Weise umgestaltet werden muss.
Diese Frage wird auch im IRC gestellt und wir haben diese Antwort bekommen: https://mozilla.logbot.info/pdfjs/20180606#c14862530 -c14862541. Kurz gesagt, ich bin mit der Webpack-Bündelung selbst nicht wirklich vertraut, aber wenn es wirklich nur für das Beispiel ist, können wir es wahrscheinlich entfernen. Bitte prüfen Sie, ob dies der Fall ist, bevor Sie eine PR einreichen.
Schließen, da dies keine gute Option ist, da #9248 zurückkehren wird, wenn wir das tun. Stattdessen sollten wir #9580 tun, die im IRC unter https://mozilla.logbot.info/pdfjs/20180606#c14862530 -c14862634 diskutiert wird.
Hilfreichster Kommentar
Hallo @timvandermeij. Danke für deine Antwort!
webpack
ist ein Build-Tool und als solches normalerweise nur als"devDependency"
sinnvoll - oder sonst auf die Build-Pipeline der Bibliothek beschränkt. Wenn Sie es als"peerDependency"
einschließen, müssen Benutzer es entweder lokal installieren (auch wenn sie es möglicherweise nicht benötigen / es nicht interessiert) oder die Warnung ignorieren, die jedes Mal aufnpm install
.Ich bin mit
worker-loader
nicht vertraut, also nimm meine Kommentare mit einer Prise Salz. Aber wenn es wie jeder anderewebpack
Loader ist, werden sie normalerweise nur als Build-Konfigurationsschritt benötigt und sonst nichts. Außerdem macht es wenig Sinn in einem Kontext, in dem die Bibliothek außerhalb des Webs verwendet werden soll (wie Node).Funktioniert
pdf.js
in einigen Fällen als eine Artwebpack
Plugin? Wenn es _ist_, _könnte_ es sinnvoll sein, sowohl den Loader als auchwebpack
als Abhängigkeit einzuschließen. Aber selbst dann würde ich argumentieren, dass diese Art von Unterstützung in ein eigenes Repository/Modul extrahiert werden sollte.Ich habe mir die Freiheit genommen, das Repo zu forken und alles, was mit
webpack
tun hat, herauszunehmen. Bei mir funktioniert es in meiner Node-Anwendung immer noch absolut einwandfrei.