Pdf.js: Webpack peerDependency aus dem pdfjs-dist Projekt löschen

Erstellt am 17. Mai 2018  ·  7Kommentare  ·  Quelle: mozilla/pdf.js

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 .

1-other

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 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.

Alle 7 Kommentare

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.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen