Pdf.js: Las instrucciones del paquete web todavía hacen que se cargue un 'trabajador falso'

Creado en 7 sept. 2016  ·  32Comentarios  ·  Fuente: mozilla/pdf.js

Configuración:

  • Navegador web y su versión: Chrome 52
  • Sistema operativo y su versión: OS X Yosemite
  • Versión PDF.js: 1.4.237
  • Es una extensión: No

Pasos para reproducir el problema:
Mi codigo es:

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

exactamente como se describe en https://github.com/mozilla/pdf.js/wiki/Setup-pdf.js-in-a-website#with -webpack,
sin embargo, obtengo un Warning: Setting up fake worker.' en mi consola cuando realmente cargo un documento, lo que hace que parezca que las instrucciones no funcionaron.

Además, la redacción de las instrucciones parece incorrecta, ya que "PDFJS.workerSrc _deberá_ configurarse para apuntar a este archivo" (la redacción actual) significa que se configura automáticamente, mientras que "PDFJS.workerSrc _debe_ configurarse para apuntar a este archivo" significa que tiene para configurarlo usted mismo.
El código de ejemplo tampoco es extremadamente útil, ya que utiliza las rutas relativas al repositorio ( pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js'; ) que una persona que importa PDFJS no podría hacer.

También estoy confundido cuando busqué problemas / PR que tienen menos de 1 año, como https://github.com/mozilla/pdf.js/pull/6595, que cargan automáticamente el script de trabajo, pero ese código parece para que ya no exista en el repositorio, por lo que tanto la configuración como la no configuración de workerSrc hacen que el trabajador falso se cargue por mí ... El trabajador falso sabe dónde encontrar el script de trabajador creado por el paquete web (por ejemplo, 1.bundle.js es el trabajador cuando bundle.js es el script), así que estoy confundido por qué un trabajador real no podría usar esta lógica también.
Intenté apuntar workerSrc al archivo 1.bundle.js creado e incluso usar el cargador de trabajo del paquete web para crear una instancia y reemplazar PDFWorker ( pdflib.PDFJS.PDFWorker = require('worker!pdfjs-dist/build/pdf.worker.entry.js') ), pero no tampoco funciona, así que estoy completamente perdido en cuanto a cómo se supone que debe trabajar el trabajador con el paquete web

1-other
Fuente
picture agilgur5
👍4

Comentario más útil

Me encontré con el mismo problema con mi proyecto de paquete web, pero lo resolví de manera diferente. En lugar de depender de la agrupación o los cargadores del paquete web, utilicé CopyWebpackPlugin para copiar la fuente del trabajador en mi directorio de compilación.

En mi visor:

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'
      }])
   }]
}
picture ctowler en 7 nov. 2016
👍21 ❤5 🎉4

Todos 32 comentarios

El trabajador falso sabe dónde encontrar el script de trabajador creado por el paquete web (por ejemplo, 1.bundle.js es el trabajador cuando bundle.js es el script), así que estoy confundido por qué un trabajador real no podría usar esta lógica también.

Verifique si bundle.js incluye trabajador; está mal (por el rendimiento y el tamaño de carga de la página) tenerlo allí. Todo el archivo pdf.worker.js se colocará en un paquete separado.

El código de ejemplo tampoco es extremadamente útil, ya que utiliza las rutas relativas al repositorio (pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js';) que una persona importa PDFJS obviamente no podría hacerlo (no es un ejemplo muy útil).

archivo pdf.worker.bundle.js que crea como un paquete de salida que incluye el módulo pdf.worker.js (importado de pdfjs-dist)

La descripción del problema no está clara. ¿Puede proporcionar un código fuente de ejemplo completo?

yurydelendik picture yurydelendik en 8 sept. 2016
👍2

Verifique si bundle.js incluye trabajador; está mal (por el rendimiento y el tamaño de carga de la página) tenerlo allí. Todo el archivo pdf.worker.js se colocará en un paquete separado.

Verificó el código incluido y puede confirmar que no incluye al trabajador. Como mencioné, el script de trabajador se incluye como 1.bundle.js . Al cargar un PDF, se inserta una etiqueta de script para 1.bundle.js en mi etiqueta <head> (no estoy seguro si es de PDFJS o paquete web).

archivo pdf.worker.bundle.js que crea como un paquete de salida que incluye el módulo pdf.worker.js (importado de pdfjs-dist)

¿Hay algún ejemplo que utilice el primer método, y posiblemente el preferido, en la Wiki de cargar el script de trabajo desde node_modules ? De la sección wiki: "El trabajador se integrará en un paquete separado: tome el archivo" ./node_modules/pdfjs-dist/build/pdf.worker.entry.js "

@yurydelendik, ¿ podría dar más detalles sobre la detección / carga automática del trabajador en # 6595 que parece que ya no está en la base de código? Estoy construyendo una biblioteca que usa pdf.js, por lo que si alguien tuviera que importar el código pdf.js para que mi biblioteca funcione, sería bastante tedioso (administrar dependencias de dependencias).

La descripción del problema no está clara. ¿Puede proporcionar un código fuente de ejemplo completo?

No adjunté el código fuente ya que no hay mucho más útil o relevante, pero aquí hay un resumen de ~ 50 líneas: http://pastebin.com/raw/PHs6bfby. El argumento file es literalmente un archivo de un elemento <input type='file' /> .

agilgur5 picture agilgur5 en 8 sept. 2016
👍1

@yurydelendik, ¿ podría dar más detalles sobre la detección / carga automática del trabajador en # 6595 que parece que ya no está en la base de código?

Esta funcionalidad no está destinada a los empaquetadores.

Estoy construyendo una biblioteca que usa pdf.js, por lo que si alguien tuviera que importar el código pdf.js para que mi biblioteca funcione, sería un poco molesto (administrar dependencias de dependencias).

Hasta ahora no hemos encontrado un paquete que administre correctamente el trabajador web y no queremos dar preferencias al paquete web o al navegador; tuvimos problemas para admitir ambos al mismo tiempo.

La solución es gestionar las dependencias de las dependencias no es trivial. Pero tenga en cuenta que el análisis y la reproducción eficientes de archivos PDF no es una tarea trivial. Si abandona el uso del trabajador web y es libre de hacerlo, el rendimiento de la interfaz de usuario se verá afectado y será su compensación.

No adjunté el código fuente porque realmente no hay mucho más útil o relevante

Puede publicar un pequeño ejemplo de una biblioteca que demuestre la intención de lo que está tratando de lograr. Los fragmentos de código proporcionados no son útiles ya que no son: ejecutables y no lo que está tratando de hacer: una biblioteca.

yurydelendik picture yurydelendik en 8 sept. 2016

Estoy experimentando el mismo problema. Consulte https://cdn.kidoju.com/support/viewer/index.html.
El código se puede encontrar en https://github.com/kidoju/Kidoju-Help. Utilice el archivo build cmd.
Consulte también https://github.com/kidoju/Kidoju-Help/issues/2.

jlchereau picture jlchereau en 9 sept. 2016

Esta funcionalidad no está destinada a los empaquetadores.

No me di cuenta de eso 👍

Hasta ahora no hemos encontrado un paquete que administre correctamente el trabajador web y no queremos dar preferencias al paquete web o al navegador; tuvimos problemas para admitir ambos al mismo tiempo.
La solución es gestionar las dependencias de las dependencias no es trivial. Pero tenga en cuenta que el análisis y la reproducción eficientes de archivos PDF no es una tarea trivial. Si abandona el uso del trabajador web y es libre de hacerlo, el rendimiento de la interfaz de usuario se verá afectado y será su compensación.

@yurydelendik Estoy de acuerdo contigo, pero no creo que sea necesario hacer un intercambio. Webpack tiene worker-loader y Browserify tiene webworkify : ¿no detectar el sistema de empaquetado y usar uno u otro resolvería completamente este problema?

Parece que podría hacerse aquí: https://github.com/mozilla/pdf.js/blob/master/src/display/api.js#L1132 , usando la ruta directa a la entrada del trabajador con
var worker = require('worker!../pdf.worker.entry.js') en paquete web o
var worker = require('webworkerify')('../pdf.worker.entry.js') en browserify.
Si crees que acerté con eso, estaría feliz de escribir un PR para eso.

Puede publicar un pequeño ejemplo de una biblioteca que demuestre la intención de lo que está tratando de lograr. Los fragmentos de código proporcionados no son útiles ya que no son: ejecutables y no lo que está tratando de hacer: una biblioteca.

El fragmento que adjunto es todo el código que estaría en la biblioteca por ahora ( pdf-to-dataURL ). Podría hacer un ejemplo rápido que use ese fragmento si el ejemplo de @jlchereau no es lo suficientemente bueno (no parece requerir pdfjs-dist de NPM, por lo que no estoy seguro de la precisión)

agilgur5 picture agilgur5 en 9 sept. 2016

Webpack tiene worker-loader y Browserify tiene webworkerify: ¿no detectar el sistema de empaquetado y usar uno u otro resolvería completamente este problema?

Sí, lo intenté en el # 6785, luego en el # 6791 y luego lo revertí. Tener require('worker!... causa problemas en browserify y require('webworkerify')(...) en webpack.

Si crees que acerté con eso, estaría feliz de escribir un PR para eso.

Sí, es bueno tener relaciones públicas que trabajen. Hasta ahora, pdfjs-dist funciona de alguna manera con webpack, browserify junto con system.js y node.js; e intentaremos mantenerlo así. Gracias.

También tenga en cuenta que si el trabajador no está disponible por alguna razón (seguridad o simplemente navegador heredado), cargará el código como una etiqueta de script. Estaba planeando agregar un constructor sobrecargado para PDFWorker que aceptaría que un trabajador web es un parámetro; esto podría proporcionar la solución alternativa para algunos casos de uso de webpack / browserify.

yurydelendik picture yurydelendik en 9 sept. 2016
👍2

por cierto, el paquete web tiene un cargador de entrada que se puede usar con workerSrc

yurydelendik picture yurydelendik en 9 sept. 2016
👍1

Sí, lo intenté en el # 6785, luego en el # 6791 y luego lo revertí. Tener require ('worker! ... causa problemas en browserify y require (' webworkerify ') (...) en webpack.

¿Pero tu __webpack_require__ no marcaría aquí?
https://github.com/mozilla/pdf.js/pull/6785/commits/79c2f69c3288494c5ce2809182c896484bf4be5c#diff -5f93a8d6c23cf0a169c6ee7347477ce8R30 ¿evitar que browserify analice esa declaración? (no estoy seguro de si la parte ensure estaba causando problemas)

Sí, es bueno tener relaciones públicas que trabajen. Hasta ahora, pdfjs-dist funciona de alguna manera con webpack, browserify junto con system.js y node.js; e intentaremos mantenerlo así. Gracias.

Probablemente llegaré a esto más adelante la semana que viene. ¿Hay alguna prueba que se deba ejecutar para comparar con varios paquetes / plataformas?

Estaba planeando agregar un constructor sobrecargado para PDFWorker que aceptaría que un trabajador web es un parámetro; esto podría proporcionar la solución alternativa para algunos casos de uso de webpack / browserify.

¡Creo que esta sería una alternativa fantástica! Específicamente, si pudiera aceptar una clase Worker , entonces la gente del paquete web podría usar algo como: webworkify-webpack y la gente de browserify usa
var worker = new WorkerFromArgs('../pdf.worker.entry.js') en el caso sobrecargado.
Esto descargaría la configuración de la lógica de los cargadores de trabajadores en la tierra del usuario, por lo que los PR potencialmente desordenados que verifican la plataforma / paquete en pdf.js no son necesarios (en cualquier caso, sería el usuario instalar el cargador adecuado)

agilgur5 picture agilgur5 en 9 sept. 2016

sin embargo, recibo una Advertencia: Configuración de trabajador falso. en mi consola cuando realmente cargo un documento, lo que hace que parezca que las instrucciones no funcionaron.

Eso es increíble, pero como se indicó anteriormente, el problema no se puede abordar sin un ejemplo completo. ¿Cerramos este y esperamos al PR?

yurydelendik picture yurydelendik en 9 sept. 2016

@jlchereau dio un ejemplo https://github.com/mozilla/pdf.js/issues/7612#issuecomment -245973303 donde de manera similar puede ver Warning: Setting up fake worker en la consola y puedo dar otro si es necesario

Este problema sigue siendo relevante ya que workerSrc debería funcionar en la implementación actual, pero no es así.
En cualquier caso, el RP resolvería este problema, así que ¿no debería dejarse abierto para el seguimiento hasta entonces?

También me gustaría escuchar sus comentarios sobre mis preguntas anteriores antes de comenzar un PR (con respecto a por qué browserify se quejó cuando intentó verificar __webpack_require__ , ya que haría lo mismo en mi PR, y si hay alguna prueba que deba ejecutar para probar todos los paquetes / plataformas simultáneamente)

agilgur5 picture agilgur5 en 10 sept. 2016

@ agilgur5 , dices:

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

Consulte https://github.com/kidoju/Kidoju-Help/blob/master/src/main.js y descomente como mejor le parezca:

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 razón por la que he estado probando ambos es https://github.com/mozilla/pdf.js/blob/master/web/viewer.js y https://github.com/mozilla/pdfjs-dist/blob/master/ web / pdf_viewer.js no son iguales y he considerado más relevante mantener todos los archivos de la misma fuente / versión.

De todos modos, ambos exhiben el mismo comportamiento en lo que respecta al trabajador.

jlchereau picture jlchereau en 10 sept. 2016

@yurydelendik , no parece que hayas visto el ejemplo de pdf-to-dataURL como un pequeño paquete que exhibe este error.

Estaba planeando agregar un constructor sobrecargado para PDFWorker que aceptaría que un trabajador web es un parámetro; esto podría proporcionar la solución alternativa para algunos casos de uso de webpack / browserify.

¿Hay alguna actualización sobre esto? Como mencioné anteriormente, creo que es una solución mucho mejor que la que propuse (a la que no respondiste las preguntas que hice, así que no pude hacer un PR de todos modos) y es mucho más genérica para casos de uso futuros y otros paquetes.

agilgur5 picture agilgur5 en 1 oct. 2016
👍2

Me encontré con el mismo problema con mi proyecto de paquete web, pero lo resolví de manera diferente. En lugar de depender de la agrupación o los cargadores del paquete web, utilicé CopyWebpackPlugin para copiar la fuente del trabajador en mi directorio de compilación.

En mi visor:

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'
      }])
   }]
}
ctowler picture ctowler en 7 nov. 2016
👍21 ❤5 🎉4

@ agilgur5 , acabo de encontrarme con este problema y fue porque estaba usando CommonsChunkPlugin. En mi caso, el webworker se estaba cargando pero se encontró con un error Uncaught ReferenceError: webpackJsonp is not defined (porque ese código se extrajo a un fragmento común y no estaba disponible para el trabajador). Esto hizo que el trabajador saliera temprano y recurriera a la implementación falsa.

No puede usar CommonsChuckPlugin o usar la solución que sugirió @ctowler .

Espero que esto resuelva tu problema.

mkennedy3000 picture mkennedy3000 en 20 dic. 2016

Oigan todos,
Estaba luchando mucho para hacer que pdf.js funcionara con Webpack. La clave es que no quería que el trabajador estuviera en un archivo separado.

Si alguien se enfrenta a problemas como:

  • Warning: Setting up fake worker. mensaje,
  • Webpack creando paquetes de basura con trabajador PDF.js no funcional,
  • Webpack que incluye al trabajador dos veces en el paquete,
    definitivamente deberías echarle un vistazo.

Paso a paso

  1. Incluí raw-loader en mi package.json para poder importar archivos como texto sin formato.

    "raw-loader": "latest",

  2. Configuré Webpack de manera que pdf.worker.js se cargue a través de 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. Ahora viene la parte complicada. La única forma de pasar un trabajador a PDF.js es a través de la configuración workerSrc . Desafortunadamente, hacer cosas como

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

    no funcionará.
    ¡PERO! Podemos crear URLs sobre la marcha desde Blob s, y podemos crear Blob s a partir de cadenas sobre la marcha.
    Entonces, la solución de trabajo para mí fue:

    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. Solo una cosa más. PDF.js tiene muchas alternativas en caso de que algo salga mal al cargar el trabajador:
    js require.ensure([], function () { var worker; worker = require('./pdf.worker.js'); callback(worker.WorkerMessageHandler); });
    Si le importa el tamaño del paquete y usó pdf.worker.min como lo hice yo, Webpack se confundirá e incluirá pdf.worker.js todos modos debido a estas cosas. Lo que es aún peor, incluso la versión minificada de PDF.js requiere pdf.worker.js no minificados. Entonces, ¿cómo podemos lidiar con esta basura?
    Le decimos a Webpack que reemplace un módulo por otro, así:
    js new webpack.NormalModuleReplacementPlugin( /pdf\.worker(\.min)?\.js$/, path.join(__dirname, 'node_modules', 'pdfjs-dist', 'build', 'pdf.worker.min.js'), ),
    lo que garantiza que todos los archivos que coincidan con /pdf\.worker(\.min)?\.js$/ , más específicamente, pdf.worker.js y pdf.worker.min.js serán reemplazados por una versión reducida del mismo.

Uf. ¡Espero que esto ayude a alguien!

wojtekmaj picture wojtekmaj en 13 jul. 2017
👍12

@wojtekmaj agregamos pdfjs-dist / webpack para la configuración cero para los usuarios de webpack. Puede ver su uso en https://github.com/yurydelendik/pdfjs-react

yurydelendik picture yurydelendik en 13 jul. 2017
❤17

@yurydelendik Gracias, sí, era consciente de esto. Aunque no logré que funcionara completamente y me enfrentaba a varios problemas, ya que terminar con un archivo compilado era una necesidad para mí.

Esto se debe a que estoy trabajando en react-pdf y tiene que ser muy fácil para mis usuarios instalarlo. package.json + import, boom, nada más.

No hay forma de que pueda decirles que calculen pdf.worker.js por sí mismos, y mucho menos que escriban instrucciones para webpack, browserify y demás.

wojtekmaj picture wojtekmaj en 13 jul. 2017
👍1

tiene que ser muy fácil para mis usuarios instalarlo. package.json + import, boom, nada más.

@wojtekmaj Realmente no entiendo sus requisitos. No veo cómo agregar pdfjs-dist y usar pdfjs-dist / webpack será imposible de usar en un proyecto de componente de reacción. Y el usuario solo incluirá el primero (un proyecto de componente).

terminar con un archivo compilado era una necesidad para mí.

Un archivo compilado no es lo que desea: a) para el inicio de la página, b) almacenamiento en caché y tamaño de transmisión, c) posibles problemas con el trabajador, pero es su elección.

yurydelendik picture yurydelendik en 13 jul. 2017

@yurydelendik
Oh, lo siento, leí mal tu publicación anterior. Pensé que estabas hablando de / examples / webpack, que es algo completamente diferente. ¡Definitivamente debería actualizarse para usar pdfjs / webpack! ¡Gracias!

Una cosa más ... El uso de pdfjs-dist / webpack no impide que pdf.js intente requerir pdf.worker.js por sí solo. Termino con:

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

Cuando defino pdf.worker como una de las entradas, empeora aún más , termino con:

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

¿Cómo soluciono este problema?

wojtekmaj picture wojtekmaj en 13 jul. 2017

Después de ejecutar yarn build con mi ejemplo react-pdf anterior, tengo los siguientes archivos:

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

Eso es normal: la aplicación es 'build / static / js / main.5a79c9e3.js' (pdf.js más react), 'build / static / js / 0.974e8de4.chunk.js' es el código de reserva pdf.worker.js se carga cuando el trabajador está deshabilitado y el código de trabajador 'build / 7b14afe24b211632ecc8.worker.js'. ¿Me estoy perdiendo de algo?

@wojtekmaj , prepare el componente de reacción completo (¿ejemplo?) con la aplicación de prueba del usuario e informe en el problema separado con STR; creo que su problema particular no está relacionado con este problema.

yurydelendik picture yurydelendik en 14 jul. 2017

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

Asigne el valor así, entonces funciona ...

Gracias...

wapappdeveloper picture wapappdeveloper en 17 mar. 2018

Mientras usa la solución @yurydelendik , si alguien recibe window error 

globalObject: 'true'

En el segmento output de la configuración de su paquete web.
Parece haber un error en el paquete web, el paquete web se estropea con el objeto window cuando se trabaja con web workers . Entonces, el truco anterior resuelve ese problema.

vivektiwary picture vivektiwary en 26 oct. 2018

@wojtekmaj :
¡Gracias por tu solución! Me funciona bien en Chrome, FF, Edge, Opera, Safari. Pero como lo excluye de babel-loader no se transpila de nuevo a ES5. Entonces tengo un problema en IE11 y así sucesivamente. ¿O me estoy perdiendo algo allí?

schnetzi picture schnetzi en 6 nov. 2018

Puede que esté haciendo algo mal aquí, así que corrijan, oh gente inteligente, pero tomé el hilo de pensamiento de hice funcionar de manera mucho más simple.

En webpack.config:

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

Y luego, en mi código:

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...
varunarora picture varunarora en 18 jun. 2019
👍7

Configuración:

  • pdfjs-dist: 2.1.266
  • paquete web: 4.35.0

Oye, tuve algunos problemas para usar webpack y pdfjs (y es trabajador).

Lo que creo que sucede (no sé pdfjs lo suficiente como para estar seguro de nada)

Debido a cosas del paquete web, tuve este error al intentar cargar el trabajador:

image

No pude encontrar nada para arreglarlo.
vendors_pdfjsWorker existía pero no estaba en esta ruta. En mi caso, quiero que el trabajador esté en el mismo lugar donde está pdf.js.
Al principio intenté cambiar workerSrc, como explicó wojtekmaj. Pero pdfjs no utilizó mi workerSrc para obtener el trabajador. Cambio de análisis de paquete web 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;
  }

DENTRO

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

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

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

Entonces, fakeWorkerFilesLoader está configurado (l.9932):
fakeWorkerFilesLoader = useRequireEnsure ? function () {

Entonces, mi workerSrc no se obtiene porque se define fakeWorkerFilesLoader:

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

Como lo resolví

En mi configuración de paquete web agregué:

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

Y luego tuve este error:
image

Me dice que mi script "ecm_viewer.worker.js" no existe.
Agregué una entrada en la configuración de mi paquete web:

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

Y funciona perfectamente, incluso si elimino la función noParse. No pude depurar el error real hasta que agregué esta opción de paquete web noParse.

No sé si estoy en el lugar adecuado para escribir esto; Puedo mover mi publicación en stackoverflow o en otro lugar. Puede ayudar a alguien algún día.

Barzou picture Barzou en 24 jul. 2019

Me encontré con el mismo problema con mi proyecto de paquete web, pero lo resolví de manera diferente. En lugar de depender de la agrupación o los cargadores del paquete web, utilicé CopyWebpackPlugin para copiar la fuente del trabajador en mi directorio de compilación.

En mi visor:

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

Esto solucionó un problema que mi equipo ha estado buscando durante SEMANAS. Gracias @ctowler : D <3

Wolven531 picture Wolven531 en 2 ago. 2019

Mientras usa la solución @yurydelendik , si alguien recibe window error 

globalObject: 'true'

En el segmento output de la configuración de su paquete web.
Parece haber un error en el paquete web, el paquete web se estropea con el objeto window cuando se trabaja con web workers . Entonces, el truco anterior resuelve ese problema.

@vivektiwary Me encuentro con el mismo problema. Sigue diciendo ReferenceError: Can't find variable: window

Puse esa configuración globalObject:'true' en el archivo Webpack.config pero la aplicación ahora no se carga en absoluto. ¿Estás seguro de que funcionó?

taihuuho picture taihuuho en 29 oct. 2019

Mientras usa la solución @yurydelendik , si alguien recibe window error 

globalObject: 'true'

En el segmento output de la configuración de su paquete web.
Parece haber un error en el paquete web, el paquete web se estropea con el objeto window cuando se trabaja con web workers . Entonces, el truco anterior resuelve ese problema.

@vivektiwary Me encuentro con el mismo problema. Sigue diciendo ReferenceError: Can't find variable: window

Puse esa configuración globalObject:'true' en el archivo Webpack.config pero la aplicación ahora no se carga en absoluto. ¿Estás seguro de que funcionó?

Sí @taihuuho , ¿pusiste eso en el obj de salida en la configuración?
Por cierto, ¿cuál es el error que está recibiendo?

vivektiwary picture vivektiwary en 30 oct. 2019

@vivektiwary Recibo este error ReferenceError: Can't find variable: window cuando uso ese pdfjs-dist/webpack

taihuuho picture taihuuho en 30 oct. 2019

Puede que esté haciendo algo mal aquí, así que corrijan, oh gente inteligente, pero tomé el hilo de pensamiento de hice funcionar de manera mucho más simple.

En webpack.config:

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

Y luego, en mi código:

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...

Terminé usando la solución de @varunarora y eso funciona muy bien. Aparentemente, esta página de documentación para Webpack https://github.com/mozilla/pdf.js/tree/master/examples/webpack no parece funcionar para todos

taihuuho picture taihuuho en 30 oct. 2019
👍1

Sin necesidad de editar la configuración del paquete web:

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

o

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;

y, por supuesto, asegúrese de tener file-loader instalado.

Estoy usando electron-forge que causó que el cargador de archivos pusiera al trabajador en un directorio, así que tuve que usar

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

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

thomassuckow picture thomassuckow en 21 ene. 2020
👍4

El uso del cargador de archivos de alguna manera tuvo efectos secundarios en el resto de mi aplicación, porque otras bibliotecas lo necesitan. Entonces, la otra forma que encontré es obtener el archivo pdf.worker.js de un cdn:

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

Marcvander picture Marcvander en 3 jun. 2020
¿Fue útil esta página
5 / 5 - 1 calificaciones

Temas relacionados

THausherr picture THausherr  ·  3Comentarios
azetutu picture azetutu  ·  4Comentarios
dmisdm picture dmisdm  ·  3Comentarios
jigskpatel picture jigskpatel  ·  3Comentarios
zerr0s picture zerr0s  ·  3Comentarios