Pdf.js: Les instructions Webpack provoquent toujours le chargement d'un `` faux travailleur ''

Créé le 7 sept. 2016  ·  32Commentaires  ·  Source: mozilla/pdf.js

Configuration:

  • Navigateur Web et sa version: Chrome 52
  • Système d'exploitation et sa version: OS X Yosemite
  • Version PDF.js: 1.4.237
  • Est une extension: Non

Étapes pour reproduire le problème:
Mon code est:

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

exactement comme décrit dans https://github.com/mozilla/pdf.js/wiki/Setup-pdf.js-in-a-website#with -webpack,
pourtant j'obtiens un Warning: Setting up fake worker.' dans ma console quand je charge réellement un document, ce qui donne l'impression que les instructions n'ont pas fonctionné.

De plus, le libellé des instructions semble incorrect car "PDFJS.workerSrc _shall_ être configuré pour pointer vers ce fichier" (le libellé actuel) signifie qu'il est automatiquement défini, alors que "PDFJS.workerSrc _ devrait_ être configuré pour pointer vers ce fichier" signifie que vous avez pour le régler vous-même.
L' exemple de code n'est pas non plus extrêmement utile car il utilise les chemins relatifs dans le référentiel ( pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js'; ) qu'une personne important PDFJS ne serait pas en mesure de faire.

Je suis également confus lorsque j'ai cherché dans les problèmes / PR qui ont moins d'un an, comme https://github.com/mozilla/pdf.js/pull/6595 qui effectuent un chargement automatique du script de travail, mais ce code semble n'existerait plus dans le dépôt, donc le paramétrage et le non-paramétrage du workerSrc provoquent le chargement du faux worker pour moi ... Le faux worker sait où trouver le script worker construit par webpack (par exemple 1.bundle.js est le worker quand bundle.js est le script), donc je ne comprends pas pourquoi un vrai worker ne pourrait pas utiliser cette logique également.
J'ai essayé de pointer workerSrc vers le fichier 1.bundle.js créé et même d'utiliser le chargeur de travail de webpack pour instancier et remplacer PDFWorker ( pdflib.PDFJS.PDFWorker = require('worker!pdfjs-dist/build/pdf.worker.entry.js') ), mais cela n'a pas ne fonctionne pas non plus, donc je suis complètement perdu quant à la façon dont le travailleur est censé travailler avec webpack

1-other

Commentaire le plus utile

J'ai rencontré le même problème avec mon projet Webpack, mais je l'ai résolu différemment. Au lieu de me fier au regroupement ou aux chargeurs de webpack, j'ai utilisé le CopyWebpackPlugin pour copier la source de travail dans mon répertoire de construction.

Dans mon spectateur:

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`;
}

En 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'
      }])
   }]
}

Tous les 32 commentaires

Le faux worker sait où trouver le script de worker construit par webpack (par exemple 1.bundle.js est le worker lorsque bundle.js est le script), donc je ne comprends pas pourquoi un vrai worker ne pourrait pas utiliser cette logique également.

Vérifiez si bundle.js inclut le worker - il est faux (à partir des performances et de la taille de chargement de la page) de l'avoir là. L'ensemble du fichier pdf.worker.js doit être placé dans un paquet séparé.

L'exemple de code n'est pas non plus extrêmement utile car il utilise les chemins relatifs dans le référentiel (pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js';) qu'une personne importe PDFJS ne serait évidemment pas en mesure de le faire (pas un exemple très utile).

fichier pdf.worker.bundle.js que vous créez en tant que sortie groupée qui inclut le module pdf.worker.js (importé de pdfjs-dist)

La description du problème n'est pas claire. Pouvez-vous fournir un exemple de code source complet?

Vérifiez si bundle.js inclut le worker - il est faux (à partir des performances et de la taille de chargement de la page) de l'avoir là. L'ensemble du fichier pdf.worker.js doit être placé dans un paquet séparé.

Vérifié le code fourni et peut confirmer Il n'inclut pas le travailleur. Comme je l'ai mentionné, le script de travail est regroupé sous la forme 1.bundle.js . Lors du chargement d' un fichier PDF, une balise de script pour 1.bundle.js est inséré dans mon <head> tag (pas sûr si cela est de PDFJS ou webpack).

fichier pdf.worker.bundle.js que vous créez en tant que sortie groupée qui inclut le module pdf.worker.js (importé de pdfjs-dist)

Existe-t-il un exemple qui utilise la première méthode, et sans doute préférée, du Wiki pour charger le script de travail à partir de node_modules ? De la section wiki: "Le worker doit être construit dans un bundle séparé: prenez le fichier" ./node_modules/pdfjs-dist/build/pdf.worker.entry.js "

@yurydelendik pourriez-vous élaborer sur l'auto-détection / chargement du worker dans # 6595 qui semble ne plus être dans la base de code? Je construis une bibliothèque qui utilise pdf.js, donc si quelqu'un devait importer du code pdf.js pour faire fonctionner ma bibliothèque, ce serait assez fastidieux (gérer les dépendances des dépendances).

La description du problème n'est pas claire. Pouvez-vous fournir un exemple de code source complet?

Je n'ai pas joint de code source car il n'y a vraiment pas grand chose d'autre utile ou pertinent, mais voici un résumé d'environ 50 lignes: http://pastebin.com/raw/PHs6bfby. L'argument file est littéralement un fichier d'un élément <input type='file' /> .

@yurydelendik pourriez-vous élaborer sur l'auto-détection / chargement du worker dans # 6595 qui semble ne plus être dans la base de code?

Cette fonctionnalité n'est pas destinée aux bundlers / packagers.

Je construis une bibliothèque qui utilise pdf.js, donc si quelqu'un devait importer du code pdf.js pour faire fonctionner ma bibliothèque, ce serait un peu ennuyeux (gérer les dépendances des dépendances).

Jusqu'à présent, nous n'avons pas trouvé de bundler qui gère correctement le web worker et nous ne voulons pas donner de préférences à webpack ou browserify - nous avons eu des problèmes avec la prise en charge des deux en même temps.

La solution est que la gestion des dépendances des dépendances n'est pas anodine. Mais gardez à l'esprit qu'une analyse et un rendu efficaces des fichiers PDF ne sont pas une tâche triviale. Si vous abandonnez l'utilisation du travailleur Web et que vous êtes libre de le faire, les performances de l'interface utilisateur en souffriront et ce sera votre compromis.

Je n'ai pas joint de code source car il n'y a vraiment pas grand chose d'autre utile ou pertinent

Vous pouvez publier un petit exemple de bibliothèque qui démontre l'intention de ce que vous essayez d'accomplir. Les extraits de code fournis ne sont pas utiles car ils ne sont pas: exécutables et non ce que vous essayez de faire - une bibliothèque.

Je rencontre le même problème. Voir https://cdn.kidoju.com/support/viewer/index.html.
Le code peut être trouvé sur https://github.com/kidoju/Kidoju-Help. Utilisez le fichier build cmd.
Voir également https://github.com/kidoju/Kidoju-Help/issues/2.

Cette fonctionnalité n'est pas destinée aux bundlers / packagers.

Je n'ai pas réalisé que 👍

Jusqu'à présent, nous n'avons pas trouvé de bundler qui gère correctement le web worker et nous ne voulons pas donner de préférences à webpack ou browserify - nous avons eu des problèmes avec la prise en charge des deux en même temps.
La solution est que la gestion des dépendances des dépendances n'est pas anodine. Mais gardez à l'esprit qu'une analyse et un rendu efficaces des fichiers PDF ne sont pas une tâche triviale. Si vous abandonnez l'utilisation du travailleur Web et que vous êtes libre de le faire, les performances de l'interface utilisateur en souffriront et ce sera votre compromis.

@yurydelendik Je suis d'accord avec vous mais je ne pense pas qu'un compromis worker-loader et Browserify a webworkify - la détection du système de bundler et l'utilisation de l'un ou de l'autre ne résoudraient-elles pas complètement ce problème?

On dirait que cela pourrait être fait ici: https://github.com/mozilla/pdf.js/blob/master/src/display/api.js#L1132 , en utilisant le chemin direct vers l'entrée du worker avec
var worker = require('worker!../pdf.worker.entry.js') dans le webpack ou
var worker = require('webworkerify')('../pdf.worker.entry.js') dans browserify.
Si vous pensez que j'ai atteint la cible avec cela, je serais heureux d'écrire un PR pour cela.

Vous pouvez publier un petit exemple de bibliothèque qui démontre l'intention de ce que vous essayez d'accomplir. Les extraits de code fournis ne sont pas utiles car ils ne sont pas: exécutables et non ce que vous essayez de faire - une bibliothèque.

L'extrait que j'ai joint est tout le code qui serait dans la bibliothèque pour l'instant ( pdf-to-dataURL ). Je pourrais faire un exemple rapide qui utilise cet extrait de code si l'exemple de pdfjs-dist de NPM, donc je ne suis pas sûr de l'exactitude de celui-ci)

Webpack a worker-loader et Browserify a webworkerify - la détection du système de bundler et l'utilisation de l'un ou de l'autre ne résoudraient-elles pas complètement ce problème?

Oui, j'ai essayé cela au # 6785, plus tard au # 6791, puis je l'ai inversé. Avoir require('worker!... cause des problèmes dans browserify et require('webworkerify')(...) dans webpack.

Si vous pensez que j'ai atteint la cible avec cela, je serais heureux d'écrire un PR pour cela.

Oui, travailler PR sera vraiment bon d'avoir. Jusqu'à présent, pdfjs-dist fonctionne d'une manière ou d'une autre avec webpack, browserify avec system.js et node.js; et nous essaierons de le garder ainsi. Merci.

Notez également que si le worker n'est pas disponible pour une raison quelconque (sécurité ou juste navigateur hérité), il chargera le code comme une balise de script. J'avais l'intention d'ajouter un constructeur surchargé pour PDFWorker qui accepterait qu'un travailleur Web soit un paramètre - cela pourrait fournir une solution alternative pour certains cas d'utilisation de webpack / browserify.

btw, webpack a un chargeur d'entrée qui peut être utilisé avec workerSrc

Oui, j'ai essayé cela au # 6785, plus tard au # 6791, puis je l'ai inversé. Avoir require ('worker! ... cause un problème dans browserify, et require (' webworkerify ') (...) dans webpack.

Mais votre __webpack_require__ ne serait-il pas vérifié ici
https://github.com/mozilla/pdf.js/pull/6785/commits/79c2f69c3288494c5ce2809182c896484bf4be5c#diff -5f93a8d6c23cf0a169c6ee7347477ce8R30 empêcher browserify d'analyser cette déclaration? (je ne sais pas si la partie ensure causait des problèmes)

Oui, travailler PR sera vraiment bon d'avoir. Jusqu'à présent, pdfjs-dist fonctionne d'une manière ou d'une autre avec webpack, browserify avec system.js et node.js; et nous essaierons de le garder ainsi. Merci.

J'y reviendrai probablement plus tard la semaine prochaine - y a-t-il un test à exécuter pour vérifier les différents bundlers / plates-formes?

J'avais l'intention d'ajouter un constructeur surchargé pour PDFWorker qui accepterait qu'un travailleur Web soit un paramètre - cela pourrait fournir une solution alternative pour certains cas d'utilisation de webpack / browserify.

Je pense que ce serait une alternative fantastique! Plus précisément, s'il pouvait accepter une classe Worker , alors les gens de webpack pourraient utiliser quelque chose comme: webworkify-webpack et les gens de browserify utilisent
var worker = new WorkerFromArgs('../pdf.worker.entry.js') dans le cas surchargé.
Cela déchargerait la configuration de la logique des chargeurs de travail dans le domaine de l'utilisateur, de sorte que les PR potentiellement désordonnés qui vérifient la plate-forme / le bundler dans pdf.js ne sont pas nécessaires (ce serait à l'utilisateur d'installer le chargeur approprié dans tous les cas)

pourtant je reçois un avertissement: installer un faux travailleur. dans ma console lorsque je charge réellement un document, ce qui donne l'impression que les instructions n'ont pas fonctionné.

C'est génial, mais comme indiqué ci-dessus, le problème ne peut être résolu sans un exemple complet. Devons-nous fermer celui-ci et attendre le PR?

@jlchereau a donné un exemple https://github.com/mozilla/pdf.js/issues/7612#issuecomment -245973303 où vous pouvez voir de la même manière Warning: Setting up fake worker dans la console et je peux en donner un autre si besoin est

Ce problème est toujours d'actualité car workerSrc devrait fonctionner dans l'implémentation actuelle, mais ce n'est pas le cas.
Dans tous les cas, le PR résoudrait ce problème, alors cela ne devrait-il pas être laissé ouvert au suivi d'ici là?

Je voudrais également entendre vos commentaires sur mes questions ci-dessus avant de commencer un PR (en ce qui concerne les raisons pour lesquelles browserify s'est plaint lorsque vous avez essayé de vérifier __webpack_require__ , car je ferais la même chose dans mon PR, et s'il y a des tests, je devrais exécuter pour tester tous les bundlers / plates-formes simultanément)

@ agilgur5 , vous dites:

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

Voir https://github.com/kidoju/Kidoju-Help/blob/master/src/main.js et décommentez comme bon vous semble:

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');

La raison pour laquelle j'ai essayé les deux est https://github.com/mozilla/pdf.js/blob/master/web/viewer.js et https://github.com/mozilla/pdfjs-dist/blob/master/ web / pdf_viewer.js ne sont pas les mêmes et j'ai jugé plus pertinent de conserver tous les fichiers de la même source / version.

Quoi qu'il en soit, les deux ont le même comportement en ce qui concerne le travailleur.

@yurydelendik il ne semble pas que vous ayez encore consulté l'exemple de @jlchereau . J'ai également créé pdf-to-dataURL comme un petit paquet qui présente ce bogue.

J'avais l'intention d'ajouter un constructeur surchargé pour PDFWorker qui accepterait qu'un travailleur Web soit un paramètre - cela pourrait fournir une solution alternative pour certains cas d'utilisation de webpack / browserify.

Y a-t-il des mises à jour à ce sujet? Comme je l'ai mentionné précédemment, je pense que c'est une bien meilleure solution que celle que j'ai proposée (à laquelle vous n'aviez pas répondu aux questions que j'ai posées donc je ne pouvais pas vraiment faire de PR de toute façon) et est beaucoup plus générique pour les cas d'utilisation futurs et autres bundlers.

J'ai rencontré le même problème avec mon projet Webpack, mais je l'ai résolu différemment. Au lieu de me fier au regroupement ou aux chargeurs de webpack, j'ai utilisé le CopyWebpackPlugin pour copier la source de travail dans mon répertoire de construction.

Dans mon spectateur:

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`;
}

En 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'
      }])
   }]
}

@ agilgur5 , je viens de rencontrer ce problème et c'était parce que j'utilisais CommonsChunkPlugin. Dans mon cas, le webworker était en cours de chargement mais a rencontré une erreur Uncaught ReferenceError: webpackJsonp is not defined (car ce code a été extrait dans un morceau commun et n'était pas disponible pour le worker). Cela a amené le travailleur à quitter prématurément et à revenir à la fausse implémentation.

Vous pouvez soit ne pas utiliser CommonsChuckPlugin, soit utiliser la solution @ctowler suggérée.

J'espère que ceci résoudra votre problème.

Salut à tous,
J'avais beaucoup de mal à faire de pdf.js avec Webpack. L'essentiel est que je ne voulais pas que le travailleur soit dans un fichier séparé.

Si quelqu'un est confronté à des problèmes tels que:

  • Warning: Setting up fake worker. message,
  • Webpack créant des bundles poubelles avec un worker PDF.js non fonctionnel,
  • Webpack incluant le worker deux fois dans le bundle,
    vous devriez certainement y jeter un œil.

Pas à pas

  1. J'ai inclus raw-loader dans mon package.json pour pouvoir importer des fichiers en texte brut.

    "raw-loader": "latest",
    
  2. J'ai configuré Webpack de manière à ce que pdf.worker.js soit chargé via raw-loader .

      module: {
        rules: [
          {
            test: /pdf\.worker(\.min)?\.js$/,
            use: 'raw-loader',
          },
          {
            test: /\.(js|jsx)$/,
            exclude: [/node_modules/, /pdf\.worker(\.min)?\.js$/],
            use: 'babel-loader',
          },
        ],
      },
    
  3. Maintenant vient la partie délicate. Le seul moyen de transmettre un worker à PDF.js est d'utiliser le paramètre workerSrc . Malheureusement, faire des trucs comme

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

    ne fonctionnera pas.
    MAIS! Nous pouvons créer des URL à la volée à partir de Blob s, et nous pouvons créer des Blob s à partir de chaînes à la volée!
    Donc, la solution de travail pour moi était:

    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. Encore une chose. PDF.js propose de nombreuses solutions de secours en cas de problème lors du chargement du worker:
    js require.ensure([], function () { var worker; worker = require('./pdf.worker.js'); callback(worker.WorkerMessageHandler); });
    Si vous vous souciez de la taille du bundle et que vous avez utilisé pdf.worker.min comme je l'ai fait, Webpack sera confus et inclura de toute façon pdf.worker.js cause de cela. Pire encore, même la version minifiée de PDF.js appelle des pdf.worker.js non minifiés. Alors, comment pouvons-nous gérer cette merde?
    Nous disons à Webpack de remplacer un module par un autre, comme ceci:
    js new webpack.NormalModuleReplacementPlugin( /pdf\.worker(\.min)?\.js$/, path.join(__dirname, 'node_modules', 'pdfjs-dist', 'build', 'pdf.worker.min.js'), ),
    ce qui garantit que chaque fichier correspondant à /pdf\.worker(\.min)?\.js$/ - plus précisément, pdf.worker.js et pdf.worker.min.js sera remplacé par une version minifiée de celui-ci.

Phew. J'espère que cela aide n'importe qui!

@wojtekmaj nous avons ajouté pdfjs-dist / webpack pour la configuration zéro pour les utilisateurs de Webpack. Vous pouvez voir son utilisation sur https://github.com/yurydelendik/pdfjs-react

@yurydelendik Merci, oui, j'étais conscient de cela. Même si je n'ai pas réussi à le faire fonctionner pleinement et que j'ai été confronté à de nombreux problèmes, se retrouver avec un fichier compilé était une nécessité pour moi.

C'est parce que je travaille sur react-pdf et qu'il doit être super facile pour mes utilisateurs de l'installer. package.json + import, boom, rien d'autre.

Il n'y a aucun moyen que je puisse leur dire de comprendre pdf.worker.js par eux-mêmes, et encore moins d'écrire des instructions pour webpack, browserify et ainsi de suite.

il doit être très facile pour mes utilisateurs de l'installer. package.json + import, boom, rien d'autre.

@wojtekmaj Je ne comprends pas vraiment vos exigences. Je ne vois pas comment l'ajout de pdfjs-dist et l'utilisation de pdfjs-dist / webpack seront impossibles à utiliser dans un projet de composant react. Et l'utilisateur inclura simplement le premier (un projet de composant).

se retrouver avec un fichier compilé était une nécessité pour moi.

Un fichier compilé n'est pas ce que vous voulez: a) pour le démarrage de la page, b) la taille de la mise en cache et de la transmission, c) des problèmes possibles avec le worker - mais c'est votre choix.

@yurydelendik
Oh, désolé, j'ai mal lu votre précédent post. Je pensais que vous parliez de / examples / webpack, ce qui est complètement différent. Il devrait certainement être mis à jour pour utiliser pdfjs / webpack! Je vous remercie!

Encore une chose ... L'utilisation de pdfjs-dist / webpack n'empêche pas pdf.js lui-même d'essayer d'exiger pdf.worker.js seul. Je me retrouve avec:

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

Quand je définis pdf.worker comme l'une des entrées, ça devient encore pire , je me retrouve avec:

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

Comment résoudre ce problème?

Après avoir exécuté yarn build avec mon exemple react-pdf ci-dessus, j'ai les fichiers suivants:

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

C'est normal: l'application est 'build / static / js / main.5a79c9e3.js' (pdf.js plus react), 'build / static / js / 0.974e8de4.chunk.js' est le code de secours pdf.worker.js est chargé lorsque le worker est désactivé et que le code de travail 'build / 7b14afe24b211632ecc8.worker.js'. Est-ce que je manque quelque chose?

@wojtekmaj, veuillez préparer le composant de réaction complet (exemple?) avec l'application de test de l'utilisateur et le rapporter dans le problème séparé avec STR - Je pense que votre problème particulier n'est pas lié à ce problème.

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

attribuer la valeur comme ça puis ses travaux ...

Merci...

Lors de l'utilisation de la solution @yurydelendik , si quelqu'un obtient window erreur

globalObject: 'true'

Dans le segment output de votre configuration webpack.
Il semble y avoir un bogue dans webpack, webpack gâche avec window objet lorsque vous travaillez avec web workers . Le hack ci-dessus résout donc ce problème.

@wojtekmaj :
Merci pour votre solution! Cela fonctionne bien pour moi dans Chrome, FF, Edge, Opera, Safari. Mais comme vous l'excluez de babel-loader il n'est pas transpilé vers ES5. J'ai donc un problème dans IE11 et ainsi de suite. Ou est-ce que je manque quelque chose là-bas?

Je fais peut-être quelque chose de mal ici, alors s'il vous plaît, corrigez les gens intelligents, mais j'ai suivi le train de pensée de @wojtekmaj et je l'ai fait fonctionner beaucoup plus simplement.

Dans webpack.config:

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

Et puis, dans mon code:

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...

Configuration :

  • pdfjs-dist: 2.1.266
  • pack Web: 4.35.0

Hé, j'ai eu du mal à utiliser webpack et pdfjs (et c'est worker).

Ce que je pense qu'il se passe (je ne connais pas assez les pdfjs pour être sûr de quoi que ce soit)

En raison de problèmes Webpack, j'ai eu cette erreur en essayant de charger le worker:

image

Je n'ai rien trouvé pour le réparer.
vendors_pdfjsWorker existait mais n'était pas dans ce chemin. Dans mon cas, je veux que le worker soit au même endroit que pdf.js.
Au début, j'ai essayé de changer workerSrc, comme l'a expliqué wojtekmaj. Mais mon workerSrc n'a pas été utilisé par pdfjs pour obtenir le worker. Webpack parsing change 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;
  }

DANS

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

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

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

Ainsi, fakeWorkerFilesLoader est défini (l.9932):
fakeWorkerFilesLoader = useRequireEnsure ? function () {

Ensuite, mon workerSrc n'est pas obtenu car fakeWorkerFilesLoader est défini:

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

Comment je l'ai résolu

Dans ma configuration Webpack, j'ai ajouté:

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

Et puis j'ai eu cette erreur:
image

Il me dit que mon script "ecm_viewer.worker.js" n'existe pas.
J'ai ajouté une entrée dans ma configuration webpack:

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

Et cela fonctionne parfaitement, même si je supprime la fonction noParse. Je n'ai pas pu déboguer la vraie erreur jusqu'à ce que j'ajoute cette option webpack noParse.

Je ne sais pas si je suis au bon endroit pour écrire ceci; Je peux déplacer mon message sur stackoverflow ou ailleurs. Cela peut aider quelqu'un un jour.

J'ai rencontré le même problème avec mon projet Webpack, mais je l'ai résolu différemment. Au lieu de me fier au regroupement ou aux chargeurs de webpack, j'ai utilisé le CopyWebpackPlugin pour copier la source de travail dans mon répertoire de construction.

Dans mon spectateur:

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`;
}

En 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'
      }])
   }]
}

Cela a résolu un problème que mon équipe recherchait depuis des SEMAINES. Merci @ctowler : D <3

Lors de l'utilisation de la solution @yurydelendik , si quelqu'un obtient window erreur

globalObject: 'true'

Dans le segment output de votre configuration webpack.
Il semble y avoir un bogue dans webpack, webpack gâche avec window objet lorsque vous travaillez avec web workers . Le hack ci-dessus résout donc ce problème.

@vivektiwary Je rencontre le même problème. Il n'arrête pas de dire ReferenceError: Can't find variable: window

J'ai mis ce paramètre globalObject:'true' dans le fichier Webpack.config mais l'application ne se charge plus du tout. Êtes-vous sûr que cela a fonctionné?

Lors de l'utilisation de la solution @yurydelendik , si quelqu'un obtient window erreur

globalObject: 'true'

Dans le segment output de votre configuration webpack.
Il semble y avoir un bogue dans webpack, webpack gâche avec window objet lorsque vous travaillez avec web workers . Le hack ci-dessus résout donc ce problème.

@vivektiwary Je rencontre le même problème. Il n'arrête pas de dire ReferenceError: Can't find variable: window

J'ai mis ce paramètre globalObject:'true' dans le fichier Webpack.config mais l'application ne se charge plus du tout. Êtes-vous sûr que cela a fonctionné?

Oui @taihuuho , avez-vous mis cela dans la sortie obj dans la configuration?
btw quelle est l'erreur que vous obtenez?

@vivektiwary J'obtiens cette erreur ReferenceError: Can't find variable: window en utilisant ce pdfjs-dist/webpack

Je fais peut-être quelque chose de mal ici, alors s'il vous plaît, corrigez les gens intelligents, mais j'ai suivi le train de pensée de @wojtekmaj et je l'ai fait fonctionner beaucoup plus simplement.

Dans webpack.config:

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

Et puis, dans mon code:

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...

J'ai fini par utiliser la solution de @varunarora et cela fonctionne très bien. Apparemment, cette page de documentation pour Webpack https://github.com/mozilla/pdf.js/tree/master/examples/webpack ne semble pas fonctionner pour tout le monde

Sans avoir besoin de modifier la configuration du webpack:

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

ou

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;

et bien sûr, assurez-vous que file-loader installé.

J'utilise electron-forge qui a obligé le chargeur de fichiers à mettre le travailleur dans un répertoire, j'ai donc dû utiliser

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

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

L'utilisation du chargeur de fichiers a eu des effets secondaires sur le reste de mon application, car d'autres bibliothèques en ont besoin. Donc, l'autre façon que j'ai trouvée est d'obtenir le fichier pdf.worker.js à partir d'un cdn:

cf ici: https://github.com/wojtekmaj/react-pdf/issues/321#issuecomment -451291757

Cette page vous a été utile?
5 / 5 - 1 notes

Questions connexes

SehyunPark picture SehyunPark  ·  3Commentaires

patelsumit5192 picture patelsumit5192  ·  3Commentaires

anggikolo11 picture anggikolo11  ·  3Commentaires

timvandermeij picture timvandermeij  ·  4Commentaires

brandonros picture brandonros  ·  3Commentaires