Pdf.js: As instruções do Webpack ainda fazem com que o 'falso trabalhador' carregue

Criado em 7 set. 2016  ·  32Comentários  ·  Fonte: mozilla/pdf.js

Configuração:

  • Navegador da web e sua versão: Chrome 52
  • Sistema operacional e sua versão: OS X Yosemite
  • Versão PDF.js: 1.4.237
  • É uma extensão: Não

Etapas para reproduzir o problema:
Meu código é:

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

exatamente como descrito em https://github.com/mozilla/pdf.js/wiki/Setup-pdf.js-in-a-website#with -webpack,
ainda assim, recebo Warning: Setting up fake worker.' em meu console quando realmente carrego um documento, o que faz parecer que as instruções não funcionaram.

Além disso, o texto nas instruções parece errado, pois "PDFJS.workerSrc _shall_ deve ser definido para apontar para este arquivo" (o texto atual) significa que ele está definido automaticamente, enquanto "PDFJS.workerSrc _deve_ ser definido para apontar para este arquivo" significa que você tem para definir você mesmo.
O código de exemplo também não é extremamente útil, pois usa os caminhos relativos para o repositório ( pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js'; ) que uma pessoa importando PDFJS não seria capaz de fazer.

Também estou confuso ao pesquisar problemas / PRs com <1 ano de idade, como https://github.com/mozilla/pdf.js/pull/6595 que carregam automaticamente o script do trabalhador, mas parece que o código para não existir mais no repo, então definir e não definir o workerSrc faz com que o falso trabalhador carregue para mim ... O falso trabalhador sabe onde encontrar o script do trabalhador criado pelo webpack (por exemplo, 1.bundle.js é o trabalhador quando bundle.js é o script), então estou confuso por que um trabalhador real não poderia usar essa lógica também.
Eu tentei apontar workerSrc para o arquivo 1.bundle.js criado e até mesmo usar o worker-loader do webpack para instanciar e substituir PDFWorker ( pdflib.PDFJS.PDFWorker = require('worker!pdfjs-dist/build/pdf.worker.entry.js') ), mas isso não também não funciona, então estou completamente perdido em como o trabalhador deve trabalhar com o webpack

1-other
Fonte
picture agilgur5
👍4

Comentários muito úteis

Encontrei o mesmo problema com meu projeto webpack, mas resolvi de forma diferente. Em vez de depender do empacotamento ou dos carregadores do webpack, usei o

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

Em 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 em 7 nov. 2016
👍21 ❤5 🎉4

Todos 32 comentários

O falso trabalhador sabe onde encontrar o script do trabalhador criado pelo webpack (por exemplo, 1.bundle.js é o trabalhador quando bundle.js é o script), então estou confuso por que um trabalhador real não poderia usar essa lógica também.

Verifique se bundle.js inclui o trabalhador - é errado (pelo desempenho e tamanho do carregamento da página) tê-lo aqui. Todo o arquivo pdf.worker.js deve ser colocado em um pacote separado.

O código de exemplo também não é extremamente útil, pois usa os caminhos relativos para o repositório (pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js';) que uma pessoa importando O PDFJS obviamente não seria capaz de fazer (não é um exemplo muito útil).

arquivo pdf.worker.bundle.js que você cria como uma saída de pacote que inclui o módulo pdf.worker.js (importado de pdfjs-dist)

A descrição do problema não é clara. Você pode fornecer um exemplo de código-fonte completo?

yurydelendik picture yurydelendik em 8 set. 2016
👍2

Verifique se bundle.js inclui o trabalhador - é errado (pelo desempenho e tamanho do carregamento da página) tê-lo aqui. Todo o arquivo pdf.worker.js deve ser colocado em um pacote separado.

Foi verificado o código agrupado e pode confirmar que não inclui o trabalhador. Como mencionei, o script de trabalho é empacotado como 1.bundle.js . Ao carregar um PDF, uma tag de script para 1.bundle.js é inserida em minha tag <head> (não tenho certeza se é de PDFJS ou webpack).

arquivo pdf.worker.bundle.js que você cria como uma saída de pacote que inclui o módulo pdf.worker.js (importado de pdfjs-dist)

Existe um exemplo que usa o primeiro, e sem dúvida preferido, método no Wiki de carregar o script de trabalho de node_modules ? Na seção wiki: "O trabalhador deve ser integrado em um pacote separado: pegue o arquivo" ./node_modules/pdfjs-dist/build/pdf.worker.entry.js "

@yurydelendik você poderia

A descrição do problema não é clara. Você pode fornecer um exemplo de código-fonte completo?

Eu não anexei o código-fonte porque não há muito mais nada útil ou relevante, mas aqui está um resumo de aproximadamente 50 linhas: http://pastebin.com/raw/PHs6bfby. O argumento file é literalmente um arquivo de um elemento <input type='file' /> .

agilgur5 picture agilgur5 em 8 set. 2016
👍1

@yurydelendik você poderia

Esta funcionalidade não se destina a empacotadores / empacotadores.

Estou construindo uma biblioteca que usa pdf.js, então se alguém tivesse que importar o código pdf.js para fazer minha biblioteca funcionar, isso seria um pouco chato (gerenciamento de dependências de dependências).

Até agora, não encontramos um bundler que gerencie adequadamente o web worker e não queremos dar preferências para webpack ou browserify - tivemos problemas com o suporte de ambos ao mesmo tempo.

A solução é gerenciar dependências de dependências não é trivial. Mas tenha em mente que a análise e renderização eficientes de PDFs não é uma tarefa trivial. Se você abandonar o uso do web worker e estiver livre para fazer isso, o desempenho da interface do usuário será prejudicado e será sua compensação.

Não anexei o código-fonte porque não há muito mais nada útil ou relevante

Você pode publicar um pequeno exemplo de uma biblioteca que demonstra a intenção do que você está tentando alcançar. Os snippets fornecidos do código não são úteis, pois não são: executáveis ​​e não o que você está tentando fazer - uma biblioteca.

yurydelendik picture yurydelendik em 8 set. 2016

Eu estou experimentando o mesmo problema. Consulte https://cdn.kidoju.com/support/viewer/index.html.
O código pode ser encontrado em https://github.com/kidoju/Kidoju-Help. Use o arquivo build cmd.
Veja também https://github.com/kidoju/Kidoju-Help/issues/2.

jlchereau picture jlchereau em 9 set. 2016

Esta funcionalidade não se destina a empacotadores / empacotadores.

Não percebi isso 👍

Até agora, não encontramos um bundler que gerencie adequadamente o web worker e não queremos dar preferências para webpack ou browserify - tivemos problemas com o suporte de ambos ao mesmo tempo.
A solução é gerenciar dependências de dependências não é trivial. Mas tenha em mente que a análise e renderização eficientes de PDFs não é uma tarefa trivial. Se você abandonar o uso do web worker e estiver livre para fazer isso, o desempenho da interface do usuário será prejudicado e será sua compensação.

@yurydelendik Concordo com você, mas não acho que essa troca precise ser feita. Webpack tem worker-loader e Browserify tem webworkify - detectar o sistema bundler e usar um ou outro resolveria completamente este problema?

Parece que isso poderia ser feito aqui: https://github.com/mozilla/pdf.js/blob/master/src/display/api.js#L1132 , usando o caminho direto para a entrada do trabalhador com
var worker = require('worker!../pdf.worker.entry.js') no webpack ou
var worker = require('webworkerify')('../pdf.worker.entry.js') no browserify.
Se você acha que atingi o alvo com isso, ficaria feliz em escrever um PR para isso.

Você pode publicar um pequeno exemplo de uma biblioteca que demonstra a intenção do que você está tentando alcançar. Os snippets fornecidos do código não são úteis, pois não são: executáveis ​​e não o que você está tentando fazer - uma biblioteca.

O snippet que anexei é todo o código que estaria na biblioteca por enquanto ( pdf-to-dataURL ). Eu poderia fazer um exemplo rápido que usa esse snippet se o exemplo de @jlchereau não for bom o suficiente (ele não parece exigir pdfjs-dist do NPM, então não tenho certeza sobre a precisão dele)

agilgur5 picture agilgur5 em 9 set. 2016

Webpack tem worker-loader e Browserify tem webworkerify - detectar o sistema bundler e usar um ou outro resolveria completamente este problema?

Sim, eu tentei isso em # 6785, mais tarde em # 6791 e depois reverti. Ter require('worker!... causa problemas no browserify e require('webworkerify')(...) no webpack.

Se você acha que atingi o alvo com isso, ficaria feliz em escrever um PR para isso.

Sim, trabalhar como RP será muito bom. Até agora, o pdfjs-dist funciona de alguma forma com webpack, browserify junto com system.js e node.js; e vamos tentar mantê-lo assim. Obrigado.

Observe também que se o trabalhador não estiver disponível por algum motivo (segurança ou apenas navegador legado), ele deve carregar o código como uma tag de script. Eu estava planejando adicionar um construtor sobrecarregado para PDFWorker que aceitaria um trabalhador da web como um parâmetro - isso pode fornecer a solução alternativa para alguns casos de uso de webpack / browserify.

yurydelendik picture yurydelendik em 9 set. 2016
👍2

btw, webpack tem carregador de entrada que pode ser usado com workerSrc

yurydelendik picture yurydelendik em 9 set. 2016
👍1

Sim, eu tentei isso em # 6785, mais tarde em # 6791 e depois reverti. Ter require ('worker! ... causa problema no browserify, e require (' webworkerify ') (...) no webpack.

Mas não seria o seu __webpack_require__ verificar aqui
https://github.com/mozilla/pdf.js/pull/6785/commits/79c2f69c3288494c5ce2809182c896484bf4be5c#diff -5f93a8d6c23cf0a169c6ee7347477ce8R30 impediu o browserify de analisar essa declaração? (não tenho certeza se a parte ensure estava causando problemas)

Sim, trabalhar como RP será muito bom. Até agora, o pdfjs-dist funciona de alguma forma com webpack, browserify junto com system.js e node.js; e vamos tentar mantê-lo assim. Obrigado.

Provavelmente chegarei a isso na próxima semana - há um teste a ser executado para verificar vários bundlers / plataformas?

Eu estava planejando adicionar um construtor sobrecarregado para PDFWorker que aceitaria um trabalhador da web como um parâmetro - isso pode fornecer a solução alternativa para alguns casos de uso de webpack / browserify.

Acho que seria uma alternativa fantástica! Especificamente, se pudesse aceitar uma classe Worker , então o pessoal do webpack poderia usar algo como: webworkify-webpack e o pessoal do browserify usam o
var worker = new WorkerFromArgs('../pdf.worker.entry.js') no caso de sobrecarga.
Isso descarregaria a configuração da lógica dos carregadores de trabalho na terra do usuário, de modo que os PRs potencialmente confusos que verificam a plataforma / bundler em pdf.js não são necessários (seria responsabilidade do usuário instalar o carregador adequado em qualquer caso)

agilgur5 picture agilgur5 em 9 set. 2016

mas recebo um aviso: configurando trabalhador falso. ' no meu console quando eu realmente carrego um documento, o que faz parecer que as instruções não funcionaram.

Isso é incrível, mas como afirmado acima, o problema não pode ser resolvido sem um exemplo completo. Vamos fechar este e aguardar o PR?

yurydelendik picture yurydelendik em 9 set. 2016

@jlchereau deu um exemplo https://github.com/mozilla/pdf.js/issues/7612#issuecomment -245973303 onde você pode ver Warning: Setting up fake worker no console e eu posso dar outro se necessário

Este problema ainda é relevante porque workerSrc deveria funcionar na implementação atual, mas não funciona.
Em qualquer caso, o PR resolveria esse problema, então não deveria ser deixado em aberto para rastreamento até então?

Também gostaria de ouvir seus comentários às minhas perguntas acima antes de iniciar um PR (sobre por que o browserify reclamou quando você tentou verificar __webpack_require__ , já que faria o mesmo em meu PR, e se houver algum teste, devo execute para testar todos os bundlers / plataformas simultaneamente)

agilgur5 picture agilgur5 em 10 set. 2016

@ agilgur5 , você diz:

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 e descomente como achar necessário:

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

O motivo pelo qual tenho tentado ambos é https://github.com/mozilla/pdf.js/blob/master/web/viewer.js e https://github.com/mozilla/pdfjs-dist/blob/master/ web / pdf_viewer.js não são os mesmos e considerei mais relevante manter todos os arquivos da mesma fonte / versão.

De qualquer forma, ambos apresentam o mesmo comportamento em relação ao trabalhador.

jlchereau picture jlchereau em 10 set. 2016

@yurydelendik , não parece que você verificou o exemplo de @jlchereau ainda. Também criei pdf-to-dataURL como um pequeno pacote que exibe esse bug.

Eu estava planejando adicionar um construtor sobrecarregado para PDFWorker que aceitaria um trabalhador da web como um parâmetro - isso pode fornecer a solução alternativa para alguns casos de uso de webpack / browserify.

Há alguma atualização sobre isso? Como mencionei anteriormente, acho que é uma solução muito melhor do que a que propus (para a qual você não respondeu às perguntas que fiz, então eu realmente não poderia fazer um PR de qualquer maneira) e é muito mais genérica para casos de uso futuros e outros empacotadores.

agilgur5 picture agilgur5 em 1 out. 2016
👍2

Encontrei o mesmo problema com meu projeto webpack, mas resolvi de forma diferente. Em vez de depender do empacotamento ou dos carregadores do webpack, usei o

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

Em 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 em 7 nov. 2016
👍21 ❤5 🎉4

@ agilgur5 , acabei de encontrar esse problema porque estava usando o CommonsChunkPlugin. No meu caso, o webworker estava carregando, mas encontrou um erro Uncaught ReferenceError: webpackJsonp is not defined (porque o código foi puxado para um pedaço comum e não estava disponível para o trabalhador). Isso fez com que o trabalhador saísse mais cedo e recuasse para a implementação falsa.

Você não pode usar o CommonsChuckPlugin ou usar a solução sugerida por @ctowler .

Espero que isso resolva seu problema.

mkennedy3000 picture mkennedy3000 em 20 dez. 2016

Olá a todos,
Eu estava lutando muito para fazer pdf.js funcionando com Webpack. O mais importante é que eu não queria que o trabalhador estivesse em um arquivo separado.

Se alguém está enfrentando problemas como:

  • Warning: Setting up fake worker. mensagem,
  • Webpack criando pacotes de lixo com trabalhador PDF.js não funcional,
  • Webpack incluindo trabalhador duas vezes no pacote,
    você definitivamente deveria dar uma olhada.

Passo a passo

  1. Incluí raw-loader no meu package.json para poder importar arquivos como texto simples.

    "raw-loader": "latest",

  2. Eu configurei o Webpack de forma que o pdf.worker.js seja carregado 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. Agora vem a parte complicada. A única maneira de passar um trabalhador para PDF.js é por meio da configuração workerSrc . Infelizmente, fazendo coisas como

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

    não vai funcionar.
    MAS! Podemos criar URLs dinamicamente a partir de Blob s e podemos criar Blob s a partir de strings dinamicamente!
    Então, a solução de trabalho para mim foi:

    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. Só mais uma coisa. PDF.js tem muitos substitutos no caso de algo dar errado ao carregar o trabalhador:
    js require.ensure([], function () { var worker; worker = require('./pdf.worker.js'); callback(worker.WorkerMessageHandler); });
    Se você se preocupa com o tamanho do pacote e usou pdf.worker.min como eu fiz, o Webpack ficará confuso e incluirá pdf.worker.js qualquer maneira por causa disso. E o que é ainda pior, mesmo a versão reduzida do PDF.js pede pdf.worker.js não minimizados. Então, como podemos lidar com essa porcaria?
    Dizemos ao Webpack para substituir um módulo por outro, assim:
    js new webpack.NormalModuleReplacementPlugin( /pdf\.worker(\.min)?\.js$/, path.join(__dirname, 'node_modules', 'pdfjs-dist', 'build', 'pdf.worker.min.js'), ),
    que garante que todos os arquivos correspondentes a /pdf\.worker(\.min)?\.js$/ - mais especificamente, pdf.worker.js e pdf.worker.min.js serão substituídos por uma versão reduzida do mesmo.

Ufa. Espero que isso ajude alguém!

wojtekmaj picture wojtekmaj em 13 jul. 2017
👍12

@wojtekmaj adicionamos pdfjs-dist / webpack para configuração zero para usuários de webpack. Você pode ver seu uso em https://github.com/yurydelendik/pdfjs-react

yurydelendik picture yurydelendik em 13 jul. 2017
❤17

@yurydelendik Obrigado, sim, eu estava ciente disso. Embora eu não tenha conseguido fazê-lo funcionar totalmente e estivesse enfrentando vários problemas, terminar com um arquivo compilado era uma necessidade para mim.

Isso ocorre porque estou trabalhando no react-pdf e deve ser muito fácil para meus usuários instalá-lo. package.json + import, boom, nada mais.

De jeito nenhum eu poderia dizer a eles para descobrirem pdf.worker.js por conta própria, muito menos escrever instruções para webpack, browserify e outros enfeites.

wojtekmaj picture wojtekmaj em 13 jul. 2017
👍1

deve ser muito fácil para meus usuários instalá-lo. package.json + import, boom, nada mais.

@wojtekmaj Eu realmente não entendo seus requisitos. Não vejo como adicionar pdfjs-dist e usar pdfjs-dist / webpack será impossível de usar em um projeto de componente react. E o usuário incluirá apenas o primeiro (um projeto de componente).

terminar com um arquivo compilado era uma necessidade para mim.

Um arquivo compilado não é o que você quer: a) para inicialização da página, b) cache e tamanho de transmissão, c) possíveis problemas com o trabalhador - mas a escolha é sua.

yurydelendik picture yurydelendik em 13 jul. 2017

@yurydelendik
Oh, desculpe, eu li errado seu post anterior. Achei que você estivesse falando sobre / examples / webpack, que é uma coisa completamente diferente. Definitivamente deve ser atualizado para usar pdfjs / webpack! Obrigado!

Mais uma coisa ... Usar pdfjs-dist / webpack não impede que o próprio pdf.js tente exigir o pdf.worker.js sozinho. Eu acabo com:

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

Quando defino pdf.worker como uma das entradas, fica ainda pior , acabo com:

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

Como faço para corrigir esse problema?

wojtekmaj picture wojtekmaj em 13 jul. 2017

Depois de executar yarn build com meu exemplo react-pdf acima, obtive os seguintes arquivos:

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

Isso é normal: o aplicativo é 'build / static / js / main.5a79c9e3.js' (pdf.js mais react), 'build / static / js / 0.974e8de4.chunk.js' é pdf.worker.js código substituto é carregado quando o trabalhador está desabilitado e o código do trabalhador 'build / 7b14afe24b211632ecc8.worker.js'. Estou esquecendo de algo?

@wojtekmaj, por favor, prepare o componente de reação completo (exemplo?) com o aplicativo de teste do usuário e relate o problema separado com STR - acho que seu problema específico não está relacionado a esse problema.

yurydelendik picture yurydelendik em 14 jul. 2017

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

atribua o valor assim, então funciona ...

Obrigado...

wapappdeveloper picture wapappdeveloper em 17 mar. 2018

Ao usar a solução @yurydelendik , se alguém obtiver um erro window não definido, coloque

globalObject: 'true'

No segmento output da configuração do seu webpack.
Parece haver um bug no webpack, o webpack bagunça o objeto window ao trabalhar com web workers . Portanto, o hack acima resolve esse problema.

vivektiwary picture vivektiwary em 26 out. 2018

@wojtekmaj :
Obrigado pela sua solução! Funciona bem para mim no Chrome, FF, Edge, Opera, Safari. Mas como você o exclui de babel-loader ele não é transpilado de volta para ES5. Portanto, recebo um problema no IE11 e assim por diante. Ou estou perdendo alguma coisa aí?

schnetzi picture schnetzi em 6 nov. 2018

Posso estar fazendo algo errado aqui, então, por favor, corrijam, gente esperta, mas peguei a linha de pensamento de @wojtekmaj e fiz com que funcionasse de maneira muito mais simples.

Em webpack.config:

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

E então, no meu código:

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

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

Configuração:

  • pdfjs-dist: 2.1.266
  • webpack: 4.35.0

Ei, eu tive alguns problemas ao usar webpack e pdfjs (e é trabalhador).

O que eu acho que acontece (não sei pdfjs o suficiente para ter certeza de nada)

Devido a coisas do webpack, tive este erro ao tentar carregar o trabalhador:

image

Não consegui encontrar nada para consertar.
vendors_pdfjsWorker existia, mas não estava neste caminho. No meu caso, quero que o trabalhador esteja no mesmo lugar onde o pdf.js está.
No início, tentei mudar o workerSrc, como wojtekmaj explicou. Mas meu workerSrc não foi usado pelo pdfjs para obter o trabalhador. Pdfjs de alteração de análise do Webpack (1.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;
  }

PARA DENTRO

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

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

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

Portanto, fakeWorkerFilesLoader está definido (1.9932):
fakeWorkerFilesLoader = useRequireEnsure ? function () {

Então, meu workerSrc não é obtido, porque fakeWorkerFilesLoader está definido:

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

Como eu resolvi isso

Na configuração do meu webpack, adicionei:

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

E então eu tive este erro:
image

Ele me diz que meu script "ecm_viewer.worker.js" não existe.
Eu adicionei uma entrada na configuração do meu webpack:

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

E funciona perfeitamente, mesmo se eu remover a função noParse. Não fui capaz de depurar o erro real até adicionar esta opção do webpack noParse.

Não sei se estou no lugar certo para escrever isso; Posso mover minha postagem no stackoverflow ou em outro lugar. Isso pode ajudar alguém um dia.

Barzou picture Barzou em 24 jul. 2019

Encontrei o mesmo problema com meu projeto webpack, mas resolvi de forma diferente. Em vez de depender do empacotamento ou dos carregadores do webpack, usei o

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

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

Isso corrigiu um problema que minha equipe estava procurando há SEMANAS. Obrigado @ctowler : D <3

Wolven531 picture Wolven531 em 2 ago. 2019

Ao usar a solução @yurydelendik , se alguém obtiver um erro window não definido, coloque

globalObject: 'true'

No segmento output da configuração do seu webpack.
Parece haver um bug no webpack, o webpack bagunça o objeto window ao trabalhar com web workers . Portanto, o hack acima resolve esse problema.

@vivektiwary Estou tendo o mesmo problema. Ele continua dizendo ReferenceError: Can't find variable: window

Coloquei aquela configuração globalObject:'true' no arquivo Webpack.config, mas o aplicativo agora não carrega de jeito nenhum. Tem certeza de que funcionou?

taihuuho picture taihuuho em 29 out. 2019

Ao usar a solução @yurydelendik , se alguém obtiver um erro window não definido, coloque

globalObject: 'true'

No segmento output da configuração do seu webpack.
Parece haver um bug no webpack, o webpack bagunça o objeto window ao trabalhar com web workers . Portanto, o hack acima resolve esse problema.

@vivektiwary Estou tendo o mesmo problema. Ele continua dizendo ReferenceError: Can't find variable: window

Coloquei aquela configuração globalObject:'true' no arquivo Webpack.config, mas o aplicativo agora não carrega de jeito nenhum. Tem certeza de que funcionou?

Sim @taihuuho , você colocou isso no obj de saída na configuração?
btw qual é o erro que você está recebendo?

vivektiwary picture vivektiwary em 30 out. 2019

@vivektiwary Estou recebendo este erro ReferenceError: Can't find variable: window ao usar aquele pdfjs-dist/webpack

taihuuho picture taihuuho em 30 out. 2019

Posso estar fazendo algo errado aqui, então, por favor, corrijam, gente esperta, mas peguei a linha de pensamento de @wojtekmaj e fiz com que funcionasse de maneira muito mais simples.

Em webpack.config:

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

E então, no meu código:

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...

Acabei usando a solução da @varunarora e https://github.com/mozilla/pdf.js/tree/master/examples/webpack não parece funcionar para todos

taihuuho picture taihuuho em 30 out. 2019
👍1

Sem a necessidade de editar a configuração do 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;

e, claro, certifique-se de ter file-loader instalado.

Estou usando o electron-forge, o que fez com que o carregador de arquivos colocasse o trabalhador em um diretório, então tive 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 em 21 jan. 2020
👍4

Usar o carregador de arquivos de alguma forma teve efeitos colaterais no resto do meu aplicativo, porque outras bibliotecas precisam dele. Portanto, a outra maneira que encontrei é obter o arquivo pdf.worker.js de um cdn:

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

Marcvander picture Marcvander em 3 jun. 2020
Esta página foi útil?
5 / 5 - 1 avaliações

Questões relacionadas

zerr0s picture zerr0s  ·  3Comentários
patelsumit5192 picture patelsumit5192  ·  3Comentários
AlexP3 picture AlexP3  ·  3Comentários
THausherr picture THausherr  ·  3Comentários
SehyunPark picture SehyunPark  ·  3Comentários