Pdf.js: Webpack-Anweisungen führen weiterhin zum Laden von "Fake Worker"

Erstellt am 7. Sept. 2016  ·  32Kommentare  ·  Quelle: mozilla/pdf.js

Aufbau:

  • Webbrowser und seine Version: Chrome 52
  • Betriebssystem und seine Version: OS X Yosemite
  • PDF.js Version: 1.4.237
  • Ist eine Erweiterung: Nein

Schritte zum Reproduzieren des Problems:
Mein Code lautet:

import pdflib from 'pdfjs-dist'
pdflib.PDFJS.workerSrc = './node_modules/pdfjs-dist/build/pdf.worker.entry.js'

genau wie in https://github.com/mozilla/pdf.js/wiki/Setup-pdf.js-in-a-website#with -webpack beschrieben,
Dennoch erhalte ich ein Warning: Setting up fake worker.' in meiner Konsole, wenn ich tatsächlich ein Dokument lade, was den Anschein erweckt, als hätten die Anweisungen nicht funktioniert.

Außerdem scheint der Wortlaut in der Anleitung falsch zu sein, da "PDFJS.workerSrc _ soll auf diese Datei verweisen" (der aktuelle Wortlaut) bedeutet, dass er automatisch gesetzt wird, während "PDFJS.workerSrc _ auf diese Datei verweisen soll" bedeutet, dass Sie haben um es selbst einzustellen.
Der Beispielcode ist auch nicht sehr hilfreich, da er die relativen Pfade in das Repository ( pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js'; ) verwendet, die eine Person, die PDFJS importiert, nicht ausführen kann.

Ich bin auch verwirrt, als ich nach Problemen / PRs gesucht habe, die <1 Jahr alt sind, wie https://github.com/mozilla/pdf.js/pull/6595 , die das Arbeiterskript automatisch laden, aber dieser Code scheint im Repo nicht mehr vorhanden zu sein, so dass sowohl das Setzen als auch das Nicht-Setzen von workerSrc dass der gefälschte Worker für mich geladen wird ... Der gefälschte Worker weiß, wo sich das von webpack erstellte Worker-Skript befindet (z. B. 1.bundle.js ist der Worker, wenn bundle.js das Skript ist), daher bin ich verwirrt, warum ein echter Worker diese Logik nicht ebenfalls verwenden konnte.
Ich habe versucht, workerSrc auf die erstellte 1.bundle.js -Datei zu verweisen und sogar den Worker-Loader von Webpack zu verwenden PDFWorker ( pdflib.PDFJS.PDFWorker = require('worker!pdfjs-dist/build/pdf.worker.entry.js') ) zu instanziieren und zu ersetzen, aber das tat es nicht Ich arbeite auch nicht, also bin ich völlig verloren, wie der Arbeiter mit Webpack arbeiten soll

1-other
Quelle
picture agilgur5
👍4

Hilfreichster Kommentar

Ich bin mit meinem Webpack-Projekt auf dasselbe Problem gestoßen, habe es aber anders gelöst. Anstatt mich auf das Bündeln oder Laden von CopyWebpackPlugin verwendet, um die Worker-Quelle in mein Build-Verzeichnis zu kopieren.

In meinem Betrachter:

import pdfjsLib from 'pdfjs-dist';

if (process.env.NODE_ENV !== 'production') {
   //in dev, get it from the node_modules directory
   //NOTE: don't use the "entry" file -- the script will fail and the web worker will not be used
   pdfjsLib.PDFJS.workerSrc = `${process.env.APP_ROOT}/node_modules/pdfjs-dist/build/pdf.worker.js`;
} else {
   //in prod, get it from the build directory
   pdfjsLib.PDFJS.workerSrc = `${process.env.APP_ROOT}/build/pdf.worker.js`;
}

In webpack.config.js :

const CopyWebpackPlugin = require('copy-webpack-plugin');

return {
   //... rest of config omitted
   plugins: [{
      new CopyWebpackPlugin([{
         from: 'node_modules/pdfjs-dist/build/pdf.worker.js',
         to: 'pdf.worker.js'
      }])
   }]
}
picture ctowler am 7. Nov. 2016
👍21 ❤5 🎉4

Alle 32 Kommentare

Der gefälschte Worker weiß, wo sich das von Webpack erstellte Worker-Skript befindet (z. B. 1.bundle.js ist der Worker, wenn bundle.js das Skript ist). Daher bin ich verwirrt, warum ein echter Worker diese Logik nicht verwenden kann.

Überprüfen Sie, ob bundle.js Worker enthält - es ist falsch (aufgrund der Leistung und Größe beim Laden der Seite), es dort zu haben. Die gesamte Datei pdf.worker.js wird in einem separaten Bundle abgelegt.

Der Beispielcode ist auch nicht sehr hilfreich, da er die relativen Pfade in das Repository verwendet (pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js';), die eine Person importiert PDFJS wäre offensichtlich nicht dazu in der Lage (kein sehr nützliches Beispiel).

pdf.worker.bundle.js-Datei, die Sie als Bundle-Ausgabe erstellen, die das Modul pdf.worker.js enthält (aus pdfjs-dist importiert)

Die Beschreibung des Problems ist nicht klar. Können Sie einen vollständigen Beispielquellcode bereitstellen?

yurydelendik picture yurydelendik am 8. Sept. 2016
👍2

Überprüfen Sie, ob bundle.js Worker enthält - es ist falsch (aufgrund der Leistung und Größe beim Laden der Seite), es dort zu haben. Die gesamte Datei pdf.worker.js wird in einem separaten Bundle abgelegt.

Überprüfte den gebündelten Code und kann bestätigen, dass der Worker nicht enthalten ist. Wie bereits erwähnt, wird das Worker-Skript als 1.bundle.js gebündelt. Beim Laden einer PDF-Datei wird ein Skript-Tag für 1.bundle.js in mein <head> -Tag eingefügt (nicht sicher, ob dies aus PDFJS oder Webpack stammt).

pdf.worker.bundle.js-Datei, die Sie als Bundle-Ausgabe erstellen, die das Modul pdf.worker.js enthält (aus pdfjs-dist importiert)

Gibt es ein Beispiel, das die erste und wohl bevorzugte Methode im Wiki verwendet, um das Arbeiterskript von node_modules laden? Aus dem Wiki-Bereich: "Der Worker soll in ein separates Bundle eingebaut werden: Nehmen Sie die Datei" ./node_modules/pdfjs-dist/build/pdf.worker.entry.js ".

@yurydelendik Könnten Sie die automatische Erkennung / das Laden des Workers in # 6595

Die Beschreibung des Problems ist nicht klar. Können Sie einen vollständigen Beispielquellcode bereitstellen?

Ich habe keinen Quellcode angehängt, da es sonst nicht viel hilfreiches oder relevantes gibt, aber hier ist eine Zusammenfassung von ~ 50 Zeilen: http://pastebin.com/raw/PHs6bfby. Das Argument file ist buchstäblich eine Datei aus einem <input type='file' /> -Element.

agilgur5 picture agilgur5 am 8. Sept. 2016
👍1

@yurydelendik Könnten Sie die automatische Erkennung / das Laden des Workers in # 6595

Diese Funktionalität ist nicht für Bundler / Packager gedacht.

Ich baue eine Bibliothek, die pdf.js verwendet. Wenn also jemand pdf.js-Code importieren müsste, damit meine Bibliothek funktioniert, wäre das etwas ärgerlich (Verwalten von Abhängigkeiten von Abhängigkeiten).

Bisher haben wir keinen Bundler gefunden, der Web Worker ordnungsgemäß verwaltet, und wir möchten Webpack oder Browserify nicht bevorzugen - wir hatten Probleme, beide gleichzeitig zu unterstützen.

Die Lösung besteht darin, Abhängigkeiten von Abhängigkeiten zu verwalten, was nicht trivial ist. Beachten Sie jedoch, dass das effiziente Parsen und Rendern von PDF-Dateien keine triviale Aufgabe ist. Wenn Sie die Verwendung von Web Worker aufgeben und dies tun können, leidet die Leistung der Benutzeroberfläche und dies ist Ihr Kompromiss.

Ich habe keinen Quellcode angehängt, da es sonst nicht viel hilfreiches oder relevantes gibt

Sie können ein kleines Beispiel einer Bibliothek veröffentlichen, das die Absicht dessen demonstriert, was Sie erreichen möchten. Vorausgesetzte Ausschnitte aus dem Code sind nicht nützlich, da sie nicht ausgeführt werden können und nicht das sind, was Sie versuchen - eine Bibliothek.

yurydelendik picture yurydelendik am 8. Sept. 2016

Ich habe das gleiche Problem. Siehe https://cdn.kidoju.com/support/viewer/index.html.
Den Code finden Sie unter https://github.com/kidoju/Kidoju-Help. Verwenden Sie die Datei build cmd.
Siehe auch https://github.com/kidoju/Kidoju-Help/issues/2.

jlchereau picture jlchereau am 9. Sept. 2016

Diese Funktionalität ist nicht für Bundler / Packager gedacht.

Wusste nicht, dass 👍

Bisher haben wir keinen Bundler gefunden, der Web Worker ordnungsgemäß verwaltet, und wir möchten Webpack oder Browserify nicht bevorzugen - wir hatten Probleme, beide gleichzeitig zu unterstützen.
Die Lösung besteht darin, Abhängigkeiten von Abhängigkeiten zu verwalten, was nicht trivial ist. Beachten Sie jedoch, dass das effiziente Parsen und Rendern von PDF-Dateien keine triviale Aufgabe ist. Wenn Sie die Verwendung von Web Worker aufgeben und dies tun können, leidet die Leistung der Benutzeroberfläche und dies ist Ihr Kompromiss.

@yurydelendik Ich würde Ihnen zustimmen, aber ich denke nicht, dass ein Kompromiss geschlossen werden muss. Webpack hat Worker-Loader und Browserify hat Webworkify - würde das Erkennen des Bundlersystems und die Verwendung des einen oder anderen dieses Problem nicht vollständig lösen?

Scheint, als könnte es hier gemacht werden: https://github.com/mozilla/pdf.js/blob/master/src/display/api.js#L1132 , über den direkten Pfad zum Worker-Eintrag mit
var worker = require('worker!../pdf.worker.entry.js') im Webpack oder
var worker = require('webworkerify')('../pdf.worker.entry.js') in browserify.
Wenn Sie glauben, dass ich damit ins Schwarze getroffen habe, würde ich gerne eine PR dafür schreiben.

Sie können ein kleines Beispiel einer Bibliothek veröffentlichen, das die Absicht dessen demonstriert, was Sie erreichen möchten. Vorausgesetzte Ausschnitte aus dem Code sind nicht nützlich, da sie nicht ausgeführt werden können und nicht das sind, was Sie versuchen - eine Bibliothek.

Das Snippet, das ich angehängt habe, ist der gesamte Code, der sich derzeit in der Bibliothek befindet ( pdf-to-dataURL ). Ich könnte ein kurzes Beispiel machen, das dieses Snippet verwendet, wenn das Beispiel von @jlchereau nicht gut genug ist (es scheint nicht pdfjs-dist von NPM zu erfordern, also nicht sicher, ob es korrekt ist).

agilgur5 picture agilgur5 am 9. Sept. 2016

Webpack hat Worker-Loader und Browserify hat Webworkerify - würde die Erkennung des Bundlersystems und die Verwendung des einen oder anderen dieses Problem nicht vollständig lösen?

Ja, ich habe das bei # 6785, später bei # 6791 versucht und das dann rückgängig gemacht. Das Vorhandensein von require('worker!... führt zu Problemen bei browserify und require('webworkerify')(...) im Webpack.

Wenn Sie glauben, dass ich damit ins Schwarze getroffen habe, würde ich gerne eine PR dafür schreiben.

Ja, PR zu arbeiten wird wirklich gut sein. Bisher funktioniert pdfjs-dist irgendwie mit Webpack, browserify zusammen mit system.js und node.js; und wir werden versuchen, es so zu halten. Vielen Dank.

Beachten Sie auch, dass ein Worker, der aus irgendeinem Grund nicht verfügbar ist (Sicherheit oder nur ein älterer Browser), Code als Skript-Tag lädt. Ich hatte vor, einen überladenen Konstruktor für PDFWorker hinzuzufügen, der akzeptiert, dass ein Web-Worker ein Parameter ist. Dies könnte die alternative Lösung für einige Webpack- / Browserify-Anwendungsfälle darstellen.

yurydelendik picture yurydelendik am 9. Sept. 2016
👍2

Übrigens hat Webpack einen Entry-Loader, der mit workerSrc verwendet werden kann

yurydelendik picture yurydelendik am 9. Sept. 2016
👍1

Ja, ich habe das bei # 6785, später bei # 6791 versucht und das dann rückgängig gemacht. Das Erfordernis ('Arbeiter! ... verursacht ein Problem in browserify und erfordert (' webworkerify ') (...) im Webpack.

Aber würde Ihr __webpack_require__ hier nicht prüfen?
https://github.com/mozilla/pdf.js/pull/6785/commits/79c2f69c3288494c5ce2809182c896484bf4be5c#diff -5f93a8d6c23cf0a169c6ee7347477ce8R30 verhindern, dass die Browser-Anweisung diese Analyse analysiert? (Ich bin mir nicht sicher, ob der Teil ensure Probleme verursacht hat.)

Ja, PR zu arbeiten wird wirklich gut sein. Bisher funktioniert pdfjs-dist irgendwie mit Webpack, browserify zusammen mit system.js und node.js; und wir werden versuchen, es so zu halten. Vielen Dank.

Ich werde wahrscheinlich später in der nächsten Woche darauf zurückkommen. Gibt es einen Test, der ausgeführt werden muss, um verschiedene Bundler / Plattformen zu überprüfen?

Ich hatte vor, einen überladenen Konstruktor für PDFWorker hinzuzufügen, der akzeptiert, dass ein Web-Worker ein Parameter ist. Dies könnte die alternative Lösung für einige Webpack- / Browserify-Anwendungsfälle darstellen.

Ich denke, das wäre eine fantastische Alternative! Insbesondere dann , wenn es eine akzeptieren könnte Worker Klasse, dann könnten webpack Leute so etwas wie verwenden: webworkify-webpack und browserify Leute verwenden webworkify und nur den Lader / Worker als Argument übergeben. So wäre es
var worker = new WorkerFromArgs('../pdf.worker.entry.js') im überladenen Fall.
Dies würde die Konfiguration der Worker-Loader-Logik in das Benutzerland verlagern, sodass potenziell unordentliche PRs, die nach Plattform / Bundler in pdf.js suchen, nicht erforderlich sind (es wäre in jedem Fall Sache des Benutzers, den richtigen Loader zu installieren).

agilgur5 picture agilgur5 am 9. Sept. 2016

dennoch bekomme ich eine Warnung: Einrichten eines falschen Arbeiters. ' in meiner Konsole, wenn ich tatsächlich ein Dokument lade, was den Anschein erweckt, als hätten die Anweisungen nicht funktioniert.

Das ist großartig, aber wie oben erwähnt, kann das Problem ohne vollständiges Beispiel nicht behoben werden. Sollen wir diesen schließen und auf die PR warten?

yurydelendik picture yurydelendik am 9. Sept. 2016

@jlchereau gab ein Beispiel https://github.com/mozilla/pdf.js/issues/7612#issuecomment -245973303, wo Sie in ähnlicher Weise Warning: Setting up fake worker in der Konsole sehen können und ich bei Bedarf ein anderes geben kann

Dieses Problem ist weiterhin relevant, da workerSrc in der aktuellen Implementierung funktionieren sollte, dies jedoch nicht.
In jedem Fall würde der PR dieses Problem beheben. Sollte dies nicht bis dahin für die Nachverfolgung offen bleiben?

Ich würde auch gerne Ihr Feedback zu meinen obigen Fragen hören, bevor Sie eine PR starten (in Bezug darauf, warum sich browserify beschwert hat, als Sie versucht haben, __webpack_require__ überprüfen, wie ich es in meiner PR tun würde, und wenn es irgendwelche Tests gibt, die ich sollte ausführen, um alle Bundler / Plattformen gleichzeitig zu testen)

agilgur5 picture agilgur5 am 10. Sept. 2016

@ agilgur5 , du sagst:

The snippet I attached is all of the code that would be in the library for now (pdf-to-dataURL).
I could make a quick example that uses that snippet if <strong i="7">@jlchereau</strong>'s example isn't good enough
(it doesn't seem to require pdfjs-dist from NPM, so not sure about the accuracy of it).

Siehe https://github.com/kidoju/Kidoju-Help/blob/master/src/main.js und kommentieren Sie, wie Sie es für richtig halten:

require('../web/viewer.css');
require('../web/compatibility.js');
// require('pdfjs-dist/web/compatibility.js');
require('../web/l10n.js');
window.pdfjsDistBuildPdf = require('../build/pdf.js');
// window.pdfjsDistBuildPdf = require('pdfjs-dist/build/pdf.js');
// require('../web/debugger.js');
require('./viewer.js');

Der Grund, warum ich beide ausprobiert habe, ist https://github.com/mozilla/pdf.js/blob/master/web/viewer.js und https://github.com/mozilla/pdfjs-dist/blob/master/ web / pdf_viewer.js sind nicht gleich und ich habe es für relevanter gehalten, alle Dateien aus derselben Quelle / Version zu behalten.

Wie auch immer, beide zeigen für den Arbeitnehmer das gleiche Verhalten.

jlchereau picture jlchereau am 10. Sept. 2016

@yurydelendik es scheint nicht , wie Sie @jlchereau ausgecheckt ‚s Beispiel noch. Ich habe auch pdf-to-dataURL als winziges Paket erstellt, das diesen Fehler aufweist.

Ich hatte vor, einen überladenen Konstruktor für PDFWorker hinzuzufügen, der akzeptiert, dass ein Web-Worker ein Parameter ist. Dies könnte die alternative Lösung für einige Webpack- / Browserify-Anwendungsfälle darstellen.

Gibt es Updates dazu? Wie ich bereits erwähnt habe, ist dies meiner Meinung nach eine viel bessere Lösung als die von mir vorgeschlagene (auf die Sie die von mir gestellten Fragen nicht beantwortet haben, sodass ich ohnehin keine PR machen konnte) und die für zukünftige Anwendungsfälle weitaus allgemeiner ist andere Bündler.

agilgur5 picture agilgur5 am 1. Okt. 2016
👍2

Ich bin mit meinem Webpack-Projekt auf dasselbe Problem gestoßen, habe es aber anders gelöst. Anstatt mich auf das Bündeln oder Laden von CopyWebpackPlugin verwendet, um die Worker-Quelle in mein Build-Verzeichnis zu kopieren.

In meinem Betrachter:

import pdfjsLib from 'pdfjs-dist';

if (process.env.NODE_ENV !== 'production') {
   //in dev, get it from the node_modules directory
   //NOTE: don't use the "entry" file -- the script will fail and the web worker will not be used
   pdfjsLib.PDFJS.workerSrc = `${process.env.APP_ROOT}/node_modules/pdfjs-dist/build/pdf.worker.js`;
} else {
   //in prod, get it from the build directory
   pdfjsLib.PDFJS.workerSrc = `${process.env.APP_ROOT}/build/pdf.worker.js`;
}

In webpack.config.js :

const CopyWebpackPlugin = require('copy-webpack-plugin');

return {
   //... rest of config omitted
   plugins: [{
      new CopyWebpackPlugin([{
         from: 'node_modules/pdfjs-dist/build/pdf.worker.js',
         to: 'pdf.worker.js'
      }])
   }]
}
ctowler picture ctowler am 7. Nov. 2016
👍21 ❤5 🎉4

@ agilgur5 , ich bin gerade auf dieses Problem Uncaught ReferenceError: webpackJsonp is not defined (da dieser Code in einen gemeinsamen Block gezogen wurde und dem Worker nicht zur Verfügung stand). Dies führte dazu, dass der Worker vorzeitig ausstieg und auf die gefälschte Implementierung zurückgriff.

Sie können entweder das CommonsChuckPlugin nicht verwenden oder die von @ctowler vorgeschlagene Lösung

Hoffe das löst dein Problem.

mkennedy3000 picture mkennedy3000 am 20. Dez. 2016

Hallo zusammen,
Ich hatte große Probleme damit, pdf.js mit Webpack zum Laufen zu bringen. Der Schlüssel ist, ich wollte nicht, dass der Arbeiter in einer separaten Datei ist.

Wenn jemand Probleme hat wie:

  • Warning: Setting up fake worker. Nachricht,
  • Webpack zum Erstellen von Papierkorbpaketen mit nicht funktionsfähigem PDF.js-Worker,
  • Webpack einschließlich Worker zweimal im Bundle,
    Sie sollten auf jeden Fall einen Blick darauf werfen.

Schritt für Schritt

  1. Ich habe raw-loader in meine package.json aufgenommen, um Dateien als Klartext importieren zu können.

    "raw-loader": "latest",

  2. Ich habe Webpack so konfiguriert, dass pdf.worker.js über raw-loader geladen wird.

      module: {
    rules: [
      {
        test: /pdf\.worker(\.min)?\.js$/,
        use: 'raw-loader',
      },
      {
        test: /\.(js|jsx)$/,
        exclude: [/node_modules/, /pdf\.worker(\.min)?\.js$/],
        use: 'babel-loader',
      },
    ],
  },

  3. Jetzt kommt der schwierige Teil. Die einzige Möglichkeit, einen Worker an PDF.js zu übergeben, ist die Einstellung workerSrc . Leider mache ich Sachen wie

    pdfjsLib.PDFJS.workerSrc = require('pdfjs-dist/build/pdf.worker');

    wird nicht funktionieren.
    ABER! Wir können URLs im laufenden Betrieb aus Blob s erstellen, und wir können Blob s aus Strings im laufenden Betrieb erstellen!
    Die funktionierende Lösung für mich war also:

    const pdfjsLib = require('pdfjs-dist');
const pdfjsWorker = require('pdfjs-dist/build/pdf.worker.min');

const pdfjsWorkerBlob = new Blob([pdfjsWorker]);
const pdfjsWorkerBlobURL = URL.createObjectURL(pdfjsWorkerBlob);

pdfjsLib.PDFJS.workerSrc = pdfjsWorkerBlobURL;

    🎉: D.

  4. Nur noch eine Sache. PDF.js hat viele Fallbacks für den Fall, dass beim Laden des Workers etwas schief geht:
    js require.ensure([], function () { var worker; worker = require('./pdf.worker.js'); callback(worker.WorkerMessageHandler); });
    Wenn Sie sich für die Bundle-Größe interessieren und pdf.worker.min wie ich verwendet haben, wird Webpack verwirrt und enthält aufgrund dieses Materials ohnehin pdf.worker.js . Was noch schlimmer ist, selbst die verkleinerte Version von PDF.js fordert nicht minimierte pdf.worker.js . Wie können wir mit diesem Mist umgehen?
    Wir weisen Webpack an, ein Modul durch ein anderes zu ersetzen, genau wie folgt:
    js new webpack.NormalModuleReplacementPlugin( /pdf\.worker(\.min)?\.js$/, path.join(__dirname, 'node_modules', 'pdfjs-dist', 'build', 'pdf.worker.min.js'), ),
    Dadurch wird sichergestellt, dass jede Datei, die mit /pdf\.worker(\.min)?\.js$/ übereinstimmt - genauer gesagt pdf.worker.js und pdf.worker.min.js , durch eine minimierte Version ersetzt wird.

Puh. Hoffe das hilft jedem!

wojtekmaj picture wojtekmaj am 13. Juli 2017
👍12

@wojtekmaj Wir haben pdfjs-dist / webpack für die Nullkonfiguration für Webpack-Benutzer hinzugefügt. Sie können die Verwendung unter https://github.com/yurydelendik/pdfjs-react einsehen

yurydelendik picture yurydelendik am 13. Juli 2017
❤17

@yurydelendik Danke, ja, das war mir bewusst. Obwohl ich es nicht geschafft habe, es vollständig zum Laufen zu bringen, hatte ich viele Probleme, da es für mich eine Notwendigkeit war, eine kompilierte Datei zu erhalten.

Dies liegt daran, dass ich an React-PDF arbeite und es für meine Benutzer sehr einfach sein muss, es zu installieren. package.json + import, boom, sonst nichts.

Ich kann ihnen auf keinen Fall sagen, dass sie pdf.worker.js selbst herausfinden sollen, geschweige denn Anweisungen für Webpack, Browserify und so weiter schreiben sollen.

wojtekmaj picture wojtekmaj am 13. Juli 2017
👍1

Es muss für meine Benutzer sehr einfach sein, es zu installieren. package.json + import, boom, sonst nichts.

@wojtekmaj Ich verstehe deine Anforderungen nicht wirklich. Ich sehe nicht ein, wie es unmöglich sein wird, pdfjs-dist hinzuzufügen und pdfjs-dist / webpack in einem Reaktionskomponentenprojekt zu verwenden. Und der Benutzer wird nur das erstere (ein Komponentenprojekt) einschließen.

Am Ende war es für mich eine Notwendigkeit, eine kompilierte Datei zu haben.

Eine kompilierte Datei ist nicht das, was Sie wollen: a) für den Seitenstart, b) Caching und Übertragungsgröße, c) mögliche Probleme mit dem Worker - aber Sie haben die Wahl.

yurydelendik picture yurydelendik am 13. Juli 2017

@yurydelendik
Oh, sorry, ich habe deinen vorherigen Beitrag falsch verstanden. Ich dachte, Sie sprechen von / examples / webpack, was eine ganz andere Sache ist. Es sollte auf jeden Fall aktualisiert werden, um pdfjs / webpack zu verwenden! Vielen Dank!

Noch etwas ... Die Verwendung von pdfjs-dist / webpack hindert pdf.js selbst nicht daran, pdf.worker.js selbst zu benötigen. Am Ende habe ich:

  • entry.bundle.js
  • abcdef1234567890.worker.bundle.js

Wenn ich pdf.worker als einen der Einträge definiere, wird es noch schlimmer. Am Ende habe ich:

  • entry.bundle.js
  • abcdef1234567890.worker.bundle.js
  • pdf.worker.bundle.js

Wie behebe ich dieses Problem?

wojtekmaj picture wojtekmaj am 13. Juli 2017

Nachdem ich yarn build mit meinem obigen React-PDF-Beispiel ausgeführt habe, habe ich folgende Dateien:

...
File sizes after gzip:

  198.42 KB  build/7b14afe24b211632ecc8.worker.js
  197.76 KB  build/static/js/0.974e8de4.chunk.js
  130.14 KB  build/static/js/main.5a79c9e3.js
  4.19 KB    build/static/css/main.d852b162.css
...

Das ist normal: Die App ist 'build / static / js / main.5a79c9e3.js' (pdf.js plus reagieren), 'build / static / js / 0.974e8de4.chunk.js' ist pdf.worker.js Fallback-Code wird geladen, wenn der Worker deaktiviert ist und der Worker-Code 'build / 7b14afe24b211632ecc8.worker.js'. Vermisse ich etwas

@wojtekmaj Bitte bereiten Sie die vollständige Reaktionskomponente (Beispiel?) mit der Test-App des Benutzers vor und berichten Sie in der separaten Ausgabe mit STR - Ich denke, Ihr spezielles Problem hängt nicht mit diesem Problem zusammen.

yurydelendik picture yurydelendik am 14. Juli 2017

PDFJS.workerSrc = 'scripts.bundle.js';
PDFJS.getDocument (getPdfName) .then ((pdfFile: any) => {
this.pdfFile = pdfFile;
this.renderPdfIntoPages (pdfFile, getPdfPages, this.pdfReady);
});

Weisen Sie den Wert so zu, dann funktioniert es ...

Vielen Dank...

wapappdeveloper picture wapappdeveloper am 17. März 2018

Wenn bei der Verwendung der window erhält, geben Sie dies bitte ein

globalObject: 'true'

Im output Segment Ihrer Webpack-Konfiguration.
Es scheint einen Fehler im Webpack zu geben, das Webpack bringt das Objekt window durcheinander, wenn es mit web workers . Der obige Hack löst dieses Problem.

vivektiwary picture vivektiwary am 26. Okt. 2018

@wojtekmaj :
Vielen Dank für Ihre Lösung! Es funktioniert gut für mich in Chrome, FF, Edge, Opera, Safari. Wenn Sie es jedoch von babel-loader , wird es nicht zurück in ES5 übertragen. Also bekomme ich ein Problem in IE11 und so weiter. Oder fehlt mir dort etwas?

schnetzi picture schnetzi am 6. Nov. 2018

Ich mache hier vielleicht etwas falsch, also bitte korrigieren Sie oh kluge Leute, aber ich habe @wojtekmajs Gedankengang genommen und es viel einfacher zum

In webpack.config:

...
{
    test: /pdf\.worker(\.min)?\.js$/,
    loader: 'file-loader'
},

Und dann in meinem Code:

import PDFJS from 'pdfjs-dist';
import PDFJSWorker from 'pdfjs-dist/build/pdf.worker.min';

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...
varunarora picture varunarora am 18. Juni 2019
👍7

Aufbau :

  • pdfjs-dist: 2.1.266
  • Webpack: 4.35.0

Hey, ich hatte einige Probleme mit Webpack und PDFs (und es ist Worker).

Was ich denke, dass es passiert (ich kenne PDFs nicht genug, um mir irgendetwas sicher zu sein)

Aufgrund von Webpack-Problemen trat beim Laden des Workers der folgende Fehler auf:

image

Ich konnte nichts finden, um das Problem zu beheben.
vendor_pdfjsWorker existierte, war aber nicht auf diesem Pfad. In meinem Fall möchte ich, dass sich der Mitarbeiter an derselben Stelle befindet, an der sich pdf.js befindet.
Zuerst habe ich versucht, workerSrc zu wechseln, wie wojtekmaj erklärte. Aber mein workerSrc wurde nicht von pdfjs verwendet, um den Arbeiter zu bekommen. Webpack-Analyse ändern pdfjs (l.9915):

  if (typeof window === 'undefined') {
    isWorkerDisabled = true;

    if (typeof require.ensure === 'undefined') {
      require.ensure = require('node-ensure');
    }

    useRequireEnsure = true;
  } else if (typeof require !== 'undefined' && typeof require.ensure === 'function') {
    useRequireEnsure = true;
  }

IN

  if (typeof window === 'undefined') {
    isWorkerDisabled = true;

    if (typeof require.ensure === 'undefined') {
      require.ensure = require('node-ensure');
    }

    useRequireEnsure = true;
  } else if (true) {
    useRequireEnsure = true;
  }

Also ist fakeWorkerFilesLoader gesetzt (l.9932):
fakeWorkerFilesLoader = useRequireEnsure ? function () {

Dann wird mein workerSrc nicht abgerufen, weil fakeWorkerFilesLoader definiert ist:

    var loader = fakeWorkerFilesLoader || function () {
      return (0, _dom_utils.loadScript)(_getWorkerSrc()).then(function () {
        return window.pdfjsWorker.WorkerMessageHandler;
      });
    };

Wie ich es gelöst habe

In meiner Webpack-Konfiguration habe ich hinzugefügt:

    module: {
        noParse: (filename) => {
            return /\\node_modules\\pdfjs-dist\\build\\pdf.js/.test(filename);
        },
        rules: [
        .......................
        ]
    },

Und dann hatte ich diesen Fehler:
image

Es sagt mir, dass mein Skript "ecm_viewer.worker.js" nicht existiert.
Ich habe einen Eintrag in meine Webpack-Konfiguration eingefügt:

entry: {
    'ecm_viewer': getFileList(),
    'ecm_viewer.worker': './node_modules/pdfjs-dist/build/pdf.worker.entry',
}

Und es funktioniert perfekt, auch wenn ich die noParse-Funktion entferne. Ich konnte den eigentlichen Fehler erst debuggen, als ich diese noParse-Webpack-Option hinzufügte.

Ich weiß nicht, ob ich am richtigen Ort bin, um dies zu schreiben. Ich kann meinen Beitrag auf Stackoverflow oder woanders hin verschieben. Es kann eines Tages jemandem helfen.

Barzou picture Barzou am 24. Juli 2019

Ich bin mit meinem Webpack-Projekt auf dasselbe Problem gestoßen, habe es aber anders gelöst. Anstatt mich auf das Bündeln oder Laden von CopyWebpackPlugin verwendet, um die Worker-Quelle in mein Build-Verzeichnis zu kopieren.

In meinem Betrachter:

import pdfjsLib from 'pdfjs-dist';

if (process.env.NODE_ENV !== 'production') {
   //in dev, get it from the node_modules directory
   //NOTE: don't use the "entry" file -- the script will fail and the web worker will not be used
   pdfjsLib.PDFJS.workerSrc = `${process.env.APP_ROOT}/node_modules/pdfjs-dist/build/pdf.worker.js`;
} else {
   //in prod, get it from the build directory
   pdfjsLib.PDFJS.workerSrc = `${process.env.APP_ROOT}/build/pdf.worker.js`;
}

In webpack.config.js :

const CopyWebpackPlugin = require('copy-webpack-plugin');

return {
   //... rest of config omitted
   plugins: [{
      new CopyWebpackPlugin([{
         from: 'node_modules/pdfjs-dist/build/pdf.worker.js',
         to: 'pdf.worker.js'
      }])
   }]
}

Dies behebt ein Problem, das mein Team nach WOCHEN gesucht hat. Danke @ctowler : D <3

Wolven531 picture Wolven531 am 2. Aug. 2019

Wenn bei der Verwendung der window erhält, geben Sie dies bitte ein

globalObject: 'true'

Im output Segment Ihrer Webpack-Konfiguration.
Es scheint einen Fehler im Webpack zu geben, das Webpack bringt das Objekt window durcheinander, wenn es mit web workers . Der obige Hack löst dieses Problem.

@vivektiwary Ich ReferenceError: Can't find variable: window

Ich habe diese Einstellung globalObject:'true' in die Datei Webpack.config eingefügt, aber die App wird jetzt überhaupt nicht geladen. Bist du sicher, dass es funktioniert hat?

taihuuho picture taihuuho am 29. Okt. 2019

Wenn bei der Verwendung der window erhält, geben Sie dies bitte ein

globalObject: 'true'

Im output Segment Ihrer Webpack-Konfiguration.
Es scheint einen Fehler im Webpack zu geben, das Webpack bringt das Objekt window durcheinander, wenn es mit web workers . Der obige Hack löst dieses Problem.

@vivektiwary Ich ReferenceError: Can't find variable: window

Ich habe diese Einstellung globalObject:'true' in die Datei Webpack.config eingefügt, aber die App wird jetzt überhaupt nicht geladen. Bist du sicher, dass es funktioniert hat?

Ja @taihuuho , hast du das in der Ausgabe obj in der Konfiguration eingefügt?
Übrigens, was ist der Fehler, den Sie bekommen?

vivektiwary picture vivektiwary am 30. Okt. 2019

@vivektiwary Ich ReferenceError: Can't find variable: window wenn ich pdfjs-dist/webpack

taihuuho picture taihuuho am 30. Okt. 2019

Ich mache hier vielleicht etwas falsch, also bitte korrigieren Sie oh kluge Leute, aber ich habe @wojtekmajs Gedankengang genommen und es viel einfacher zum

In webpack.config:

...
{
    test: /pdf\.worker(\.min)?\.js$/,
    loader: 'file-loader'
},

Und dann in meinem Code:

import PDFJS from 'pdfjs-dist';
import PDFJSWorker from 'pdfjs-dist/build/pdf.worker.min';

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...

Am Ende habe ich die Lösung von https://github.com/mozilla/pdf.js/tree/master/examples/webpack nicht für alle zu funktionieren

taihuuho picture taihuuho am 30. Okt. 2019
👍1

Ohne die Webpack-Konfiguration bearbeiten zu müssen:

PDFJS.GlobalWorkerOptions.workerSrc = require('!!file-loader!pdfjs-dist/build/pdf.worker.min.js').default;

oder

import PDFJS from 'pdfjs-dist';
import PDFJSWorker from '!!file-loader!pdfjs-dist/build/pdf.worker.min.js';

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;

und natürlich stellen Sie sicher, dass Sie file-loader installiert haben.

Ich verwende Electron-Forge, was dazu führte, dass der File-Loader den Worker in ein Verzeichnis stellte, das ich verwenden musste

PDFJS.GlobalWorkerOptions.workerSrc = '../' + require('!!file-loader!pdfjs-dist/build/pdf.worker.min.js').default;

https://webpack.js.org/concepts/loaders/#inline

thomassuckow picture thomassuckow am 21. Jan. 2020
👍4

Die Verwendung von File-Loader hatte irgendwie Nebenwirkungen auf den Rest meiner App, weil andere Bibliotheken dies benötigen. Die andere Möglichkeit, die ich gefunden habe, besteht darin, die Datei pdf.worker.js von einer CDN abzurufen:

Siehe hier: https://github.com/wojtekmaj/react-pdf/issues/321#issuecomment -451291757

Marcvander picture Marcvander am 3. Juni 2020
War diese Seite hilfreich?
5 / 5 - 1 Bewertungen

Verwandte Themen

liuzhen2008 picture liuzhen2008  ·  4Kommentare
sujit-baniya picture sujit-baniya  ·  3Kommentare
aaronshaf picture aaronshaf  ·  3Kommentare
jigskpatel picture jigskpatel  ·  3Kommentare
timvandermeij picture timvandermeij  ·  4Kommentare