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

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

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?

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

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

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.

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)

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.

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

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)

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?

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

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

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

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

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

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

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.

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

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.

@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í?

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

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.

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

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?

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 Estou recebendo este erro ReferenceError: Can't find variable: window ao usar aquele pdfjs-dist/webpack

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

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

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

Esta p√°gina foi √ļtil?
5 / 5 - 1 avalia√ß√Ķes

Quest√Ķes relacionadas

smit-modi picture smit-modi  ¬∑  3Coment√°rios

azetutu picture azetutu  ¬∑  4Coment√°rios

kleins05 picture kleins05  ¬∑  3Coment√°rios

THausherr picture THausherr  ¬∑  3Coment√°rios

jigskpatel picture jigskpatel  ¬∑  3Coment√°rios