Pdf.js: Инструкции Webpack по-прежнему вызывают загрузку фальшивого работника

Созданный на 7 сент. 2016 · 32Комментарии · Источник: mozilla/pdf.js

Конфигурация:

Веб-браузер и его версия: Chrome 52
Операционная система и ее версия: OS X Yosemite
Версия PDF.js: 1.4.237
Это расширение: Нет

Шаги по воспроизведению проблемы:
Мой код:

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

точно так, как описано в https://github.com/mozilla/pdf.js/wiki/Setup-pdf.js-in-a-website#with -webpack,
но при загрузке документа я получаю Warning: Setting up fake worker.' в консоли, из-за чего кажется, что инструкции не работают.

Кроме того, формулировка в инструкциях кажется неправильной, поскольку «PDFJS.workerSrc _shall_ должен указывать на этот файл» (текущая формулировка) означает, что он устанавливается автоматически, тогда как «PDFJS.workerSrc _должен_ быть установлен, чтобы указывать на этот файл» означает, что у вас есть установить самому.
Пример кода также не очень полезен, поскольку он использует относительные пути в репозиторий ( pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js'; ), которые человек, импортирующий PDFJS, не сможет сделать.

Я также смущен, когда искал проблемы / PR, которым менее 1 года, например https://github.com/mozilla/pdf.js/pull/6595, которые выполняют автоматическую загрузку рабочего скрипта, но этот код кажется чтобы больше не существовать в репо, поэтому как установка, так и не установка workerSrc вызывают загрузку поддельного рабочего для меня ... Поддельный рабочий знает, где найти рабочий скрипт, созданный webpack (например, 1.bundle.js - это воркер, когда bundle.js - скрипт), поэтому я не понимаю, почему настоящий воркер не может использовать эту логику.
Я попытался указать workerSrc на созданный файл 1.bundle.js и даже использовать рабочий загрузчик webpack для создания и замены PDFWorker ( pdflib.PDFJS.PDFWorker = require('worker!pdfjs-dist/build/pdf.worker.entry.js') ), но это не так. тоже не работает, поэтому я совершенно не понимаю, как рабочий должен работать с webpack

1-other

Источник

agilgur5

👍4

Самый полезный комментарий

У меня возникла та же проблема с моим проектом webpack, но я решил ее по-другому. Вместо того, чтобы полагаться на бандлы или загрузчики webpack, я использовал CopyWebpackPlugin для копирования исходного кода рабочего в свою директорию сборки.

В моем зрителе:

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

В 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 7 нояб. 2016

👍21 ❤5 🎉4

Все 32 Комментарий

Поддельный воркер знает, где найти рабочий скрипт, созданный с помощью webpack (например, 1.bundle.js - это воркер, когда bundle.js скрипт), поэтому я не понимаю, почему настоящий воркер не может использовать эту логику.

Проверьте, есть ли в bundle.js воркер - это неправильно (исходя из производительности и размера загрузки страницы), чтобы он там был. Весь файл pdf.worker.js необходимо поместить в отдельный пакет.

Пример кода также не очень полезен, поскольку он использует относительные пути в репозиторий (pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js';), который импортирует человек PDFJS, очевидно, не сможет этого сделать (не очень полезный пример).

pdf.worker.bundle.js файл, который вы создаете как выходной пакет, который включает модуль pdf.worker.js (импортированный из pdfjs-dist)

Описание проблемы неясно. Можете ли вы предоставить полный пример исходного кода?

yurydelendik 8 сент. 2016

👍2

Проверьте, есть ли в bundle.js воркер - это неправильно (исходя из производительности и размера загрузки страницы), чтобы он там был. Весь файл pdf.worker.js необходимо поместить в отдельный пакет.

Проверил связанный код и могу подтвердить, что он не включает воркера. Как я уже упоминал, рабочий сценарий объединен как 1.bundle.js . При загрузке PDF-файла тег скрипта для 1.bundle.js вставляется в мой тег <head> (не уверен, из PDFJS или из веб-пакета).

pdf.worker.bundle.js файл, который вы создаете как выходной пакет, который включает модуль pdf.worker.js (импортированный из pdfjs-dist)

Есть ли в Wiki пример, который использует первый и, возможно, предпочтительный метод загрузки рабочего скрипта из node_modules ? Из раздела вики: «Воркер нужно встроить в отдельный бандл: взять файл» ./node_modules/pdfjs-dist/build/pdf.worker.entry.js »

@yurydelendik, не могли бы вы воркера в # 6595, которого, похоже, больше нет в кодовой базе? Я создаю библиотеку, в которой используется pdf.js, поэтому, если кому-то придется импортировать код pdf.js, чтобы моя библиотека работала, это было бы довольно утомительно (управление зависимостями зависимостей).

Описание проблемы неясно. Можете ли вы предоставить полный пример исходного кода?

Я не прилагал исходный код, так как на самом деле больше ничего полезного или актуального не было, но вот краткое изложение ~ 50 строк: http://pastebin.com/raw/PHs6bfby. Аргумент file - это буквально файл из элемента <input type='file' /> .

agilgur5 8 сент. 2016

👍1

@yurydelendik, не могли бы вы воркера в # 6595, которого, похоже, больше нет в кодовой базе?

Эта функция не предназначена для сборщиков / упаковщиков.

Я создаю библиотеку, в которой используется pdf.js, поэтому, если бы кому-то пришлось импортировать код pdf.js, чтобы моя библиотека работала, это было бы немного раздражающим (управление зависимостями зависимостей).

Пока мы не нашли сборщика, который должным образом управляет веб-воркером, и мы не хотим отдавать предпочтения веб-пакету или браузеру - у нас были проблемы с одновременной поддержкой обоих.

Решение состоит в том, чтобы управлять зависимостями зависимостей нетривиально. Но имейте в виду, что эффективный синтаксический анализ и рендеринг PDF-файлов - нетривиальная задача. Если вы откажетесь от использования веб-воркера и вольны это сделать, производительность пользовательского интерфейса пострадает, и это станет вашим компромиссом.

Я не прилагал исходный код, потому что на самом деле ничего полезного или актуального

Вы можете опубликовать небольшой пример библиотеки, демонстрирующий цель того, чего вы пытаетесь достичь. Предоставленные фрагменты кода бесполезны, поскольку они: не запускаемые, а не то, что вы пытаетесь сделать - библиотека.

yurydelendik 8 сент. 2016

У меня такая же проблема. См. Https://cdn.kidoju.com/support/viewer/index.html.
Код можно найти на https://github.com/kidoju/Kidoju-Help. Используйте файл build cmd.
См. Также https://github.com/kidoju/Kidoju-Help/issues/2.

jlchereau 9 сент. 2016

Эта функция не предназначена для сборщиков / упаковщиков.

Не осознавал этого 👍

Пока мы не нашли сборщика, который должным образом управляет веб-воркером, и мы не хотим отдавать предпочтения веб-пакету или браузеру - у нас были проблемы с одновременной поддержкой обоих.
Решение состоит в том, чтобы управлять зависимостями зависимостей нетривиально. Но имейте в виду, что эффективный синтаксический анализ и рендеринг PDF-файлов - нетривиальная задача. Если вы откажетесь от использования веб-воркера и вольны это сделать, производительность пользовательского интерфейса пострадает, и это станет вашим компромиссом.

@yurydelendik Я согласен с вами, но я не думаю, что нужно идти на компромисс. У Webpack есть worker-loader, а у Browserify есть webworkify - разве не обнаружение системы

Похоже, это можно сделать здесь: https://github.com/mozilla/pdf.js/blob/master/src/display/api.js#L1132 , используя прямой путь к записи рабочего с
var worker = require('worker!../pdf.worker.entry.js') в веб-пакете или
var worker = require('webworkerify')('../pdf.worker.entry.js') в браузере.
Если вы думаете, что я попал в цель, я буду счастлив написать об этом пиар.

Вы можете опубликовать небольшой пример библиотеки, демонстрирующий цель того, чего вы пытаетесь достичь. Предоставленные фрагменты кода бесполезны, поскольку они: не запускаемые, а не то, что вы пытаетесь сделать - библиотека.

Прилагаемый мною фрагмент - это весь код, который сейчас будет в библиотеке ( pdf-to-dataURL ). Я мог бы сделать быстрый пример, который использует этот фрагмент, если пример @jlchereau недостаточно хорош (похоже, он не требует pdfjs-dist от NPM, поэтому не уверен в его точности)

agilgur5 9 сент. 2016

У Webpack есть worker-loader, а у Browserify есть webworkerify - разве не обнаружение системы сборщика и использование того или другого полностью решит эту проблему?

Да, я попробовал это на # 6785, позже на # 6791, а затем вернул это. Наличие require('worker!... вызывает проблемы в браузере, а require('webworkerify')(...) в webpack.

Если вы думаете, что я попал в цель, я буду счастлив написать об этом пиар.

Да, рабочий пиар будет действительно хорош. Пока что pdfjs-dist как-то работает с webpack, browserify вместе с system.js и node.js; и мы постараемся сохранить это так. Благодарю.

Также обратите внимание, что если worker по какой-то причине недоступен (безопасность или просто устаревший браузер), он должен загрузить код как тег скрипта. Я планировал добавить перегруженный конструктор для PDFWorker, который будет принимать веб-воркер в качестве параметра - это может предоставить альтернативное решение для некоторых сценариев использования webpack / browserify.

yurydelendik 9 сент. 2016

👍2

кстати, в webpack есть загрузчик записи, который можно использовать с workerSrc

yurydelendik 9 сент. 2016

👍1

Да, я попробовал это на # 6785, позже на # 6791, а затем вернул это. Наличие require ('worker! ... вызывает проблему в браузере и require (' webworkerify ') (...) в webpack.

Но разве ваш __webpack_require__ чек здесь
https://github.com/mozilla/pdf.js/pull/6785/commits/79c2f69c3288494c5ce2809182c896484bf4be5c#diff -5f93a8d6c23cf0a169c6ee7347477ce8R30 запретить анализировать этот оператор браузером? (не уверен, что часть ensure вызывала проблемы)

Да, рабочий пиар будет действительно хорош. Пока что pdfjs-dist как-то работает с webpack, browserify вместе с system.js и node.js; и мы постараемся сохранить это так. Благодарю.

Я, вероятно, вернусь к этому позже на следующей неделе - есть ли тест, который нужно запустить для проверки на различных сборщиках / платформах?

Я планировал добавить перегруженный конструктор для PDFWorker, который будет принимать веб-воркер в качестве параметра - это может предоставить альтернативное решение для некоторых сценариев использования webpack / browserify.

Я думаю, это была бы фантастическая альтернатива! В частности, если он может принимать класс Worker , тогда люди, использующие webpack, могли бы использовать что-то вроде: webworkify-webpack и люди browserify используют webworkify и просто передают загрузчик / Worker в качестве аргумента. Так было бы
var worker = new WorkerFromArgs('../pdf.worker.entry.js') в перегруженном случае.
Это выгружает конфигурацию логики рабочих загрузчиков в пользовательскую среду, поэтому потенциально беспорядочные PR, которые проверяют платформу / сборщик в pdf.js, не нужны (в любом случае пользователь должен установить правильный загрузчик)

agilgur5 9 сент. 2016

но я получаю предупреждение: установка поддельного рабочего ». в моей консоли, когда я действительно загружаю документ, из-за чего кажется, что инструкции не работают.

Это круто, но, как указано выше, проблему невозможно решить без полного примера. Может, закроем и дождемся пиара?

yurydelendik 9 сент. 2016

@jlchereau привел один пример https://github.com/mozilla/pdf.js/issues/7612#issuecomment -245973303, где вы аналогичным образом можете увидеть Warning: Setting up fake worker в консоли, и я могу привести другой, если потребуется

Эта проблема по-прежнему актуальна, поскольку workerSrc должен работать в текущей реализации, но не работает.
В любом случае, PR решит эту проблему, не следует ли оставлять это открытым для отслеживания до тех пор?

Я также хотел бы услышать ваши отзывы на мои вопросы выше, прежде чем начинать PR (относительно того, почему browserify жаловался, когда вы пытались проверить __webpack_require__ , поскольку я бы сделал то же самое в своем PR, и если есть какие-либо тесты, я должен запустить для одновременного тестирования всех сборщиков / платформ)

agilgur5 10 сент. 2016

@ agilgur5 , вы говорите:

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

См. Https://github.com/kidoju/Kidoju-Help/blob/master/src/main.js и раскомментируйте, как считаете нужным:

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

Причина, по которой я пробовал оба, - https://github.com/mozilla/pdf.js/blob/master/web/viewer.js и https://github.com/mozilla/pdfjs-dist/blob/master/ web / pdf_viewer.js - это не одно и то же, и я счел более подходящим хранить все файлы из одного источника / версии.

В любом случае, оба демонстрируют одинаковое поведение по отношению к работнику.

jlchereau 10 сент. 2016

@yurydelendik , похоже, вы еще не проверяли пример @jlchereau . Я также сделал pdf-to-dataURL в виде крошечного пакета, который обнаруживает эту ошибку.

Я планировал добавить перегруженный конструктор для PDFWorker, который будет принимать веб-воркер в качестве параметра - это может предоставить альтернативное решение для некоторых сценариев использования webpack / browserify.

Есть ли обновления по этому поводу? Как я уже упоминал ранее, я считаю, что это гораздо лучшее решение, чем то, которое я предложил (на которое вы не ответили на вопросы, которые я задавал, поэтому я все равно не смог бы сделать PR), и гораздо более общее для будущих вариантов использования и другие сборщики.

agilgur5 1 окт. 2016

👍2

В моем зрителе:

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

В 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 7 нояб. 2016

👍21 ❤5 🎉4

@ agilgur5 , я только что столкнулся с этой проблемой, потому что я использовал CommonsChunkPlugin. В моем случае веб-работник загружался, но столкнулся с ошибкой Uncaught ReferenceError: webpackJsonp is not defined (потому что этот код был перенесен в общий блок и был недоступен для рабочего). Это привело к тому, что работник преждевременно завершил работу и вернулся к фальшивой реализации.

Вы можете либо не использовать CommonsChuckPlugin, либо использовать решение, предложенное @ctowler .

Надеюсь, это решит вашу проблему.

mkennedy3000 20 дек. 2016

Всем привет,
Я изо всех сил пытался заставить pdf.js работать с Webpack. Главное, я не хотел, чтобы воркер находился в отдельном файле.

Если кто-то сталкивается с такими проблемами, как:

Warning: Setting up fake worker. сообщение,
Webpack создает пакеты мусора с нефункциональным работником PDF.js,
Webpack, включающий два воркера в комплект,
вам обязательно стоит взглянуть.

Шаг за шагом

Я включил raw-loader в свой package.json, чтобы иметь возможность импортировать файлы в виде открытого текста.
```
"raw-loader": "latest",
```

Я настроил Webpack таким образом, чтобы pdf.worker.js загружался через 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',
      },
    ],
  },

А теперь самое сложное. Единственный способ передать воркера в PDF.js - использовать параметр workerSrc . К сожалению, делать такие вещи, как
```
pdfjsLib.PDFJS.workerSrc = require('pdfjs-dist/build/pdf.worker');
```
не сработает.
НО! Мы можем создавать URL-адреса на лету из Blob s, и мы можем создавать Blob s из строк на лету!
Итак, рабочее решение для меня было:
```
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
Еще одно. PDF.js имеет множество резервных вариантов на случай, если с загрузкой воркера что-то пойдет не так:
js require.ensure([], function () { var worker; worker = require('./pdf.worker.js'); callback(worker.WorkerMessageHandler); });
Если вы заботитесь о размере пакета и используете pdf.worker.min как я, Webpack запутается и все равно включит pdf.worker.js из-за этого. Что еще хуже, даже минифицированная версия PDF.js требует неминифицированного pdf.worker.js . Так как же нам справиться с этим дерьмом?
Мы говорим Webpack заменить один модуль другим, вот так:
js new webpack.NormalModuleReplacementPlugin( /pdf\.worker(\.min)?\.js$/, path.join(__dirname, 'node_modules', 'pdfjs-dist', 'build', 'pdf.worker.min.js'), ),
что гарантирует, что каждый файл, соответствующий /pdf\.worker(\.min)?\.js$/ а именно pdf.worker.js и pdf.worker.min.js будет заменен его уменьшенной версией.

Фух. Надеюсь, это кому-нибудь поможет!

wojtekmaj 13 июл. 2017

👍12

@wojtekmaj мы добавили pdfjs-dist / webpack для нулевой конфигурации для пользователей webpack. Вы можете увидеть его использование на https://github.com/yurydelendik/pdfjs-react

yurydelendik 13 июл. 2017

❤17

@yurydelendik Спасибо, да, я знал об этом. Хотя мне не удалось заставить его работать полностью, и я столкнулся с множеством проблем, так как в конечном итоге один скомпилированный файл был для меня необходимостью.

Это потому, что я работаю над response-pdf, и моим пользователям должно быть очень легко его установить. package.json + import, бум, больше ничего.

Я не могу сказать им, чтобы они рисовали pdf.worker.js самостоятельно, не говоря уже о том, чтобы писать инструкции для веб-пакетов, просмотра и прочего.

wojtekmaj 13 июл. 2017

👍1

Моим пользователям должно быть очень легко его установить. package.json + import, бум, больше ничего.

@wojtekmaj Я действительно не понимаю ваших требований. Я не понимаю, как добавление pdfjs-dist и использование pdfjs-dist / webpack невозможно будет использовать в проекте компонента реакции. И пользователь просто включит первый (компонентный проект).

получение одного скомпилированного файла было для меня необходимостью.

Один скомпилированный файл - это не то, что вам нужно: а) для запуска страницы, б) размер кеширования и передачи, в) возможные проблемы с воркером - но это ваш выбор.

yurydelendik 13 июл. 2017

@yurydelendik
Ой, извините, я неправильно прочитал ваш предыдущий пост. Я думал, вы говорите о / examples / webpack, это совсем другое дело. Его обязательно нужно обновить, чтобы использовать pdfjs / webpack! Спасибо!

Еще одна вещь ... Использование pdfjs-dist / webpack не останавливает сам pdf.js от попыток потребовать pdf.worker.js самостоятельно. Я получаю:

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

Когда я определяю pdf.worker как одну из записей, становится еще хуже , я получаю:

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

Как мне решить эту проблему?

wojtekmaj 13 июл. 2017

После запуска yarn build с моим примером response-pdf выше у меня есть следующие файлы:

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

Это нормально: приложение представляет собой материал build / static / js / main.5a79c9e3.js (pdf.js plus react), build / static / js / 0.974e8de4.chunk.js - резервный код pdf.worker.js загружается, когда воркер отключен и рабочий код build / 7b14afe24b211632ecc8.worker.js. Я что-то упускаю?

@wojtekmaj, пожалуйста, подготовьте полный компонент реакции (пример?) с тестовым приложением пользователя и сообщите в отдельной проблеме с STR - я думаю, ваша конкретная проблема не связана с этой проблемой.

yurydelendik 14 июл. 2017

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

назначьте такое значение, тогда его работа ...

Благодаря...

wapappdeveloper 17 мар. 2018

При использовании решения @yurydelendik, если кто-то получает ошибку window not defined, поставьте

globalObject: 'true'

В сегменте output конфигурации вашего веб-пакета.
Кажется, в webpack есть ошибка, webpack портит объект window при работе с web workers . Таким образом, описанный выше прием решает эту проблему.

vivektiwary 26 окт. 2018

@wojtekmaj :
Спасибо за решение! У меня он отлично работает в Chrome, FF, Edge, Opera, Safari. Но поскольку вы исключаете его из babel-loader он не переносится обратно в ES5. Так что у меня проблема в IE11 и так далее. Или мне что-то там не хватает?

schnetzi 6 нояб. 2018

Возможно, я здесь что-то делаю неправильно, поэтому, пожалуйста, поправьте, о, умные люди, но я взял ход мыслей @wojtekmaj и заставил его работать намного проще.

В webpack.config:

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

А затем в моем коде:

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...

varunarora 18 июн. 2019

👍7

Конфигурация:

pdfjs-dist: 2.1.266
webpack: 4.35.0

Привет, у меня были проблемы с использованием webpack и pdfjs (и он рабочий).

Что я думаю, что это происходит (я недостаточно знаю pdfjs, чтобы быть уверенным в чем-либо)

Из-за материала webpack у меня была эта ошибка при попытке загрузить worker:

Я не мог найти ничего, чтобы это исправить.
vendors_pdfjsWorker существует, но его нет на этом пути. В моем случае я хочу, чтобы воркер находился там же, где находится pdf.js.
Сначала я попытался изменить workerSrc, как объяснил Войтекмай. Но мой workerSrc не использовался pdfjs для получения рабочего. Изменение парсинга Webpack 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;
  }

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

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

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

Итак, fakeWorkerFilesLoader установлен (l.9932):
fakeWorkerFilesLoader = useRequireEnsure ? function () {

Тогда мой workerSrc не получает, потому что определен fakeWorkerFilesLoader:

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

Как я это решил

В моей конфигурации веб-пакета я добавил:

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

А потом у меня была такая ошибка:

Он сообщает мне, что мой скрипт «ecm_viewer.worker.js» не существует.
Я добавил запись в свой конфиг webpack:

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

И он отлично работает, даже если я удалю функцию noParse. Мне не удалось отладить настоящую ошибку, пока я не добавлю этот параметр веб-пакета noParse.

Я не знаю, где я пишу это; Я могу переместить свой пост в stackoverflow или куда-нибудь еще. Однажды это может кому-то помочь.

Barzou 24 июл. 2019

У меня возникла та же проблема с моим проектом webpack, но я решил ее по-другому. Вместо того, чтобы полагаться на бандлы или загрузчики webpack, я использовал CopyWebpackPlugin для копирования исходного кода рабочего в свою директорию сборки.
В моем зрителе:
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`;
}
В 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 : D <3

Wolven531 2 авг. 2019

При использовании решения @yurydelendik, если кто-то получает ошибку window not defined, поставьте
globalObject: 'true'
В сегменте output конфигурации вашего веб-пакета.
Кажется, в webpack есть ошибка, webpack портит объект window при работе с web workers . Таким образом, описанный выше прием решает эту проблему.

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

Я поместил эту настройку globalObject:'true' в файл Webpack.config, но теперь приложение вообще не загружается. Вы уверены, что это сработало?

taihuuho 29 окт. 2019

При использовании решения @yurydelendik, если кто-то получает ошибку window not defined, поставьте
globalObject: 'true'
В сегменте output конфигурации вашего веб-пакета.
Кажется, в webpack есть ошибка, webpack портит объект window при работе с web workers . Таким образом, описанный выше прием решает эту проблему.
@vivektiwary Я ReferenceError: Can't find variable: window
Я поместил эту настройку globalObject:'true' в файл Webpack.config, но теперь приложение вообще не загружается. Вы уверены, что это сработало?

Да @taihuuho , вы поместили это в выходной объект в конфигурации?
кстати, что это за ошибка, которую вы получаете?

vivektiwary 30 окт. 2019

@vivektiwary Я получаю эту ошибку ReferenceError: Can't find variable: window при использовании этого pdfjs-dist/webpack

taihuuho 30 окт. 2019

Возможно, я здесь что-то делаю неправильно, поэтому, пожалуйста, поправьте, о, умные люди, но я взял ход мыслей @wojtekmaj и заставил его работать намного проще.
В webpack.config:
...
{
    test: /pdf\.worker(\.min)?\.js$/,
    loader: 'file-loader'
},
А затем в моем коде:
import PDFJS from 'pdfjs-dist';
import PDFJSWorker from 'pdfjs-dist/build/pdf.worker.min';

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...

В итоге я использовал решение @varunarora , и оно работает очень хорошо. По-видимому, эта страница документации для Webpack https://github.com/mozilla/pdf.js/tree/master/examples/webpack работает не для всех.

taihuuho 30 окт. 2019

👍1

Без необходимости редактировать конфигурацию веб-пакета:

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

или же

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;

и, конечно, убедитесь, что у вас установлено file-loader .

Я использую electronic-forge, из-за которого загрузчик файлов помещал рабочего в каталог, поэтому мне пришлось использовать

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

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

thomassuckow 21 янв. 2020

👍4

Использование файлового загрузчика каким-то образом имело побочные эффекты для остальной части моего приложения, потому что это нужно другим библиотекам. Другой способ, который я нашел, - получить файл pdf.worker.js с компакт-диска:

cf здесь: https://github.com/wojtekmaj/react-pdf/issues/321#issuecomment -451291757