Pdf.js: Instruksi webpack masih menyebabkan 'pekerja palsu' dimuat

Dibuat pada 7 Sep 2016  ·  32Komentar  ·  Sumber: mozilla/pdf.js

Konfigurasi:

  • Browser web dan versinya: Chrome 52
  • Sistem operasi dan versinya: OS X Yosemite
  • Versi PDF.js: 1.4.237
  • Merupakan ekstensi: Tidak

Langkah-langkah untuk mereproduksi masalah:
Kode saya adalah:

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

persis seperti yang dijelaskan di https://github.com/mozilla/pdf.js/wiki/Setup-pdf.js-in-a-website#with -webpack,
namun saya mendapatkan Warning: Setting up fake worker.' di konsol saya ketika saya benar-benar memuat dokumen, yang membuatnya tampak seperti petunjuk tidak berfungsi.

Selain itu, kata-kata pada instruksi tampaknya salah karena "PDFJS.workerSrc _shall_ disetel untuk mengarah ke file ini" (kata-kata saat ini) berarti bahwa itu otomatis disetel, sedangkan "PDFJS.workerSrc _should_ disetel untuk mengarah ke file ini" berarti Anda telah untuk mengaturnya sendiri.
Kode contoh juga tidak terlalu membantu karena menggunakan jalur relatif ke dalam repositori ( pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js'; ) yang tidak dapat dilakukan oleh orang yang mengimpor PDFJS.

Saya juga bingung ketika saya mencari melalui masalah / PR yang berusia <1 tahun seperti https://github.com/mozilla/pdf.js/pull/6595 yang melakukan pemuatan otomatis skrip pekerja, tetapi kode itu tampaknya untuk tidak lagi ada di repo, jadi baik pengaturan dan tidak mengatur workerSrc menyebabkan pekerja palsu memuat untuk saya ... Pekerja palsu tahu di mana menemukan skrip pekerja yang dibangun oleh webpack (mis. 1.bundle.js adalah pekerja ketika bundle.js adalah skrip), jadi saya bingung mengapa pekerja nyata tidak dapat menggunakan logika ini juga.
Saya sudah mencoba mengarahkan workerSrc ke file 1.bundle.js dibuat dan bahkan menggunakan pekerja-loader webpack untuk membuat dan mengganti PDFWorker ( pdflib.PDFJS.PDFWorker = require('worker!pdfjs-dist/build/pdf.worker.entry.js') ), tetapi itu tidak terjadi juga tidak berfungsi, jadi saya benar-benar bingung bagaimana pekerja seharusnya bekerja dengan webpack

1-other

Komentar yang paling membantu

Saya mengalami masalah yang sama dengan proyek webpack saya, tetapi saya menyelesaikannya secara berbeda. Alih-alih mengandalkan bundling atau pemuat webpack, saya menggunakan CopyWebpackPlugin untuk menyalin sumber pekerja ke direktori build saya.

Di penampil saya:

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

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

Semua 32 komentar

Pekerja palsu tahu di mana menemukan skrip pekerja yang dibangun oleh webpack (misalnya 1.bundle.js adalah pekerja ketika bundle.js adalah skripnya), jadi saya bingung mengapa pekerja nyata tidak dapat menggunakan logika ini juga.

Periksa apakah bundle.js menyertakan pekerja - salah (dari kinerja dan ukuran pemuatan halaman) untuk memilikinya di sana. Seluruh file pdf.worker.js harus ditempatkan ke dalam bundel terpisah.

Kode contoh juga tidak terlalu membantu karena menggunakan jalur relatif ke dalam repositori (pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js';) yang diimpor oleh seseorang PDFJS jelas tidak akan bisa melakukannya (bukan contoh yang sangat berguna).

File pdf.worker.bundle.js yang Anda buat sebagai output bundel yang menyertakan modul pdf.worker.js (diimpor dari pdfjs-dist)

Deskripsi masalahnya tidak jelas. Bisakah Anda memberikan contoh kode sumber lengkap?

Periksa apakah bundle.js menyertakan pekerja - salah (dari kinerja dan ukuran pemuatan halaman) untuk memilikinya di sana. Seluruh file pdf.worker.js harus ditempatkan ke dalam bundel terpisah.

Memeriksa kode yang dibundel dan dapat mengonfirmasi Itu tidak termasuk pekerja. Seperti yang saya sebutkan, skrip pekerja dibundel sebagai 1.bundle.js . Setelah memuat PDF, tag skrip untuk 1.bundle.js dimasukkan ke dalam tag <head> (tidak yakin apakah ini dari PDFJS atau webpack).

File pdf.worker.bundle.js yang Anda buat sebagai output bundel yang menyertakan modul pdf.worker.js (diimpor dari pdfjs-dist)

Adakah contoh yang menggunakan metode pertama, dan bisa dibilang lebih disukai, dalam Wiki memuat skrip pekerja dari node_modules ? Dari bagian wiki: "Pekerja harus dibangun ke dalam bundel terpisah: ambil file" ./node_modules/pdfjs-dist/build/pdf.worker.entry.js "

@yurydelendik, bisakah Anda menjelaskan tentang deteksi otomatis / pemuatan pekerja di # 6595 yang tampaknya tidak lagi berada dalam basis kode? Saya sedang membangun perpustakaan yang menggunakan pdf.js, jadi jika seseorang harus mengimpor kode pdf.js agar perpustakaan saya berfungsi, itu akan cukup membosankan (mengelola dependensi dependensi).

Deskripsi masalahnya tidak jelas. Bisakah Anda memberikan contoh kode sumber lengkap?

Saya tidak melampirkan kode sumber karena sebenarnya tidak banyak lagi yang berguna atau relevan, tetapi berikut ~ ringkasan 50 baris: http://pastebin.com/raw/PHs6bfby. Argumen file secara harfiah adalah file dari elemen <input type='file' /> .

@yurydelendik, bisakah Anda menjelaskan tentang deteksi otomatis / pemuatan pekerja di # 6595 yang tampaknya tidak lagi berada dalam basis kode?

Fungsionalitas ini tidak ditujukan untuk pemaket / pembuat paket.

Saya sedang membangun perpustakaan yang menggunakan pdf.js, jadi jika seseorang harus mengimpor kode pdf.js agar perpustakaan saya berfungsi, itu akan sedikit mengganggu (mengelola dependensi dependensi).

Sejauh ini kami tidak menemukan bundler yang mengelola web worker dengan benar dan kami tidak ingin memberikan preferensi ke webpack atau browserify - kami mengalami masalah dalam mendukung keduanya pada saat yang bersamaan.

Solusinya adalah mengelola dependensi dependensi bukanlah hal yang sepele. Namun perlu diingat bahwa parsing dan rendering PDF yang efisien bukanlah tugas yang sepele. Jika Anda berhenti menggunakan pekerja web, dan Anda bebas melakukannya, kinerja UI akan terganggu dan itu akan menjadi kompromi Anda.

Saya tidak melampirkan kode sumber karena tidak banyak lagi yang berguna atau relevan

Anda bisa menerbitkan contoh kecil dari sebuah pustaka yang mendemonstrasikan maksud dari apa yang ingin Anda capai. Cuplikan kode yang diberikan tidak berguna karena tidak: dapat dijalankan dan bukan apa yang Anda coba lakukan - perpustakaan.

Saya mengalami masalah yang sama. Lihat https://cdn.kidoju.com/support/viewer/index.html.
Kode tersebut dapat ditemukan di https://github.com/kidoju/Kidoju-Help. Gunakan file build cmd.
Lihat juga https://github.com/kidoju/Kidoju-Help/issues/2.

Fungsionalitas ini tidak ditujukan untuk pemaket / pembuat paket.

Tidak menyadarinya 👍

Sejauh ini kami tidak menemukan bundler yang mengelola web worker dengan benar dan kami tidak ingin memberikan preferensi ke webpack atau browserify - kami mengalami masalah dalam mendukung keduanya pada saat yang bersamaan.
Solusinya adalah mengelola dependensi dependensi bukanlah hal yang sepele. Namun perlu diingat bahwa parsing dan rendering PDF yang efisien bukanlah tugas yang sepele. Jika Anda berhenti menggunakan pekerja web, dan Anda bebas melakukannya, kinerja UI akan terganggu dan itu akan menjadi kompromi Anda.

@yurydelendik Saya setuju dengan Anda tetapi saya tidak berpikir bahwa pertukaran perlu dilakukan. Webpack memiliki worker-loader dan Browserify memiliki webworkify - tidakkah mendeteksi sistem bundler dan menggunakan satu atau yang lain sepenuhnya menyelesaikan masalah ini?

Sepertinya itu bisa dilakukan di sini: https://github.com/mozilla/pdf.js/blob/master/src/display/api.js#L1132 , menggunakan jalur langsung ke entri pekerja dengan
var worker = require('worker!../pdf.worker.entry.js') dalam webpack atau
var worker = require('webworkerify')('../pdf.worker.entry.js') di browserify.
Jika Anda pikir saya mencapai sasaran dengan itu, saya akan dengan senang hati menulis PR untuk itu.

Anda bisa menerbitkan contoh kecil dari sebuah pustaka yang mendemonstrasikan maksud dari apa yang ingin Anda capai. Cuplikan kode yang diberikan tidak berguna karena tidak: dapat dijalankan dan bukan apa yang Anda coba lakukan - perpustakaan.

Cuplikan yang saya lampirkan adalah semua kode yang akan ada di perpustakaan untuk saat ini ( pdf-to-dataURL ). Saya dapat membuat contoh cepat yang menggunakan potongan itu jika contoh @jlchereau tidak cukup baik (sepertinya tidak memerlukan pdfjs-dist dari NPM, jadi tidak yakin tentang keakuratannya)

Webpack memiliki worker-loader dan Browserify memiliki webworkerify - tidakkah mendeteksi sistem bundler dan menggunakan salah satu atau yang lain sepenuhnya menyelesaikan masalah ini?

Ya, saya mencobanya di # 6785, kemudian di # 6791, lalu mengembalikannya. Memiliki require('worker!... menyebabkan masalah di browserify, dan require('webworkerify')(...) di webpack.

Jika Anda pikir saya mencapai sasaran dengan itu, saya akan dengan senang hati menulis PR untuk itu.

Ya, PR yang bekerja akan sangat bagus untuk dimiliki. Sejauh ini pdfjs-dist bekerja dengan webpack, browserify bersama dengan system.js dan node.js; dan kami akan berusaha untuk tetap seperti ini. Terima kasih.

Juga perhatikan bahwa jika pekerja tidak tersedia karena beberapa alasan (keamanan atau hanya browser lama), itu akan memuat kode sebagai tag skrip. Saya berencana untuk menambahkan konstruktor kelebihan beban untuk PDFWorker yang akan menerima pekerja web sebagai parameter - ini mungkin memberikan solusi alternatif untuk beberapa kasus penggunaan webpack / browserify.

btw, webpack memiliki entry-loader yang bisa digunakan dengan workerSrc

Ya, saya mencobanya di # 6785, kemudian di # 6791, lalu mengembalikannya. Memiliki require ('worker! ... menyebabkan masalah di browserify, dan require (' webworkerify ') (...) di webpack.

Tapi bukankah __webpack_require__ diperiksa di sini
https://github.com/mozilla/pdf.js/pull/6785/commits/79c2f69c3288494c5ce2809182c896484bf4be5c#diff -5f93a8d6c23cf0a169c6ee7347477ce8R30 mencegah browserify dari mengurai pernyataan itu? (tidak yakin apakah bagian ensure menyebabkan masalah)

Ya, PR yang bekerja akan sangat bagus untuk dimiliki. Sejauh ini pdfjs-dist bekerja dengan webpack, browserify bersama dengan system.js dan node.js; dan kami akan berusaha untuk tetap seperti ini. Terima kasih.

Saya mungkin akan membahasnya nanti minggu depan - apakah ada pengujian yang harus dijalankan untuk memeriksa berbagai bundler / platform?

Saya berencana untuk menambahkan konstruktor kelebihan beban untuk PDFWorker yang akan menerima pekerja web sebagai parameter - ini mungkin memberikan solusi alternatif untuk beberapa kasus penggunaan webpack / browserify.

Saya pikir ini akan menjadi alternatif yang fantastis! Secara khusus, jika dapat menerima kelas Worker , maka orang-orang webpack dapat menggunakan sesuatu seperti: webworkify-webpack dan browserify orang menggunakan webworkify dan hanya meneruskan loader / Worker sebagai argumen. Jadi itu akan terjadi
var worker = new WorkerFromArgs('../pdf.worker.entry.js') dalam kasus kelebihan beban.
Ini akan membongkar konfigurasi logika worker loader ke dalam lahan pengguna sehingga PR yang berpotensi berantakan yang memeriksa platform / bundler ke pdf.js tidak perlu (bagaimanapun, pengguna harus menginstal loader yang tepat)

namun saya mendapatkan Peringatan: Menyiapkan pekerja palsu. ' di konsol saya ketika saya benar-benar memuat dokumen, yang membuatnya tampak seperti instruksi tidak berfungsi.

Itu luar biasa, tetapi seperti yang dinyatakan di atas, masalahnya tidak dapat diatasi tanpa contoh lengkap. Haruskah kita menutup yang ini dan menunggu PR?

@jlchereau memberikan satu contoh https://github.com/mozilla/pdf.js/issues/7612#issuecomment -245973303 di mana Anda juga dapat melihat Warning: Setting up fake worker di konsol dan saya dapat memberikan yang lain jika perlu

Masalah ini masih relevan karena workerSrc seharusnya berfungsi dalam implementasi saat ini, tetapi tidak.
Bagaimanapun, PR akan menyelesaikan masalah ini jadi bukankah ini harus dibiarkan terbuka untuk pelacakan sampai saat itu?

Saya juga ingin mendengar tanggapan Anda untuk pertanyaan saya di atas sebelum memulai PR (mengenai mengapa browserify mengeluh ketika Anda mencoba memeriksa __webpack_require__ , karena saya akan melakukan hal yang sama di PR saya, dan jika ada tes saya harus jalankan untuk menguji semua bundler / platform secara bersamaan)

@ agilgur5 , Anda mengatakan:

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

Lihat https://github.com/kidoju/Kidoju-Help/blob/master/src/main.js dan hapus komentar sesuai keinginan Anda:

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

Alasan saya mencoba keduanya adalah https://github.com/mozilla/pdf.js/blob/master/web/viewer.js dan https://github.com/mozilla/pdfjs-dist/blob/master/ web / pdf_viewer.js tidak sama dan menurut saya lebih relevan untuk menyimpan semua file dari sumber / versi yang sama.

Bagaimanapun, keduanya menunjukkan perilaku yang sama sejauh menyangkut pekerja.

@yurydelendik sepertinya Anda belum memeriksa contoh @jlchereau . Saya juga membuat pdf-to-dataURL sebagai paket kecil yang menunjukkan bug ini.

Saya berencana untuk menambahkan konstruktor kelebihan beban untuk PDFWorker yang akan menerima pekerja web sebagai parameter - ini mungkin memberikan solusi alternatif untuk beberapa kasus penggunaan webpack / browserify.

Apakah ada pembaruan tentang ini? Seperti yang saya sebutkan sebelumnya, saya merasa itu adalah solusi yang jauh lebih baik daripada yang saya usulkan (yang Anda belum menjawab pertanyaan yang saya ajukan sehingga saya tidak bisa benar-benar membuat PR) dan jauh lebih umum untuk kasus penggunaan di masa mendatang dan bundler lainnya.

Saya mengalami masalah yang sama dengan proyek webpack saya, tetapi saya menyelesaikannya secara berbeda. Alih-alih mengandalkan bundling atau pemuat webpack, saya menggunakan CopyWebpackPlugin untuk menyalin sumber pekerja ke direktori build saya.

Di penampil saya:

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

Di 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 , Saya baru saja mengalami masalah ini dan itu karena saya menggunakan CommonsChunkPlugin. Dalam kasus saya, webworker sedang memuat tetapi mengalami kesalahan Uncaught ReferenceError: webpackJsonp is not defined (karena kode itu ditarik ke bagian umum dan tidak tersedia untuk pekerja). Ini menyebabkan pekerja keluar lebih awal dan mundur ke implementasi palsu.

Anda juga tidak dapat menggunakan CommonsChuckPlugin atau menggunakan solusi yang disarankan @ctowler .

Semoga ini menyelesaikan masalah Anda.

Hai semua,
Saya berjuang keras untuk membuat pdf.js bekerja dengan Webpack. Kuncinya adalah saya tidak ingin pekerja berada di file terpisah.

Jika ada yang menghadapi masalah seperti:

  • Warning: Setting up fake worker. pesan,
  • Webpack membuat bundel sampah dengan pekerja PDF.js non-fungsional,
  • Webpack termasuk pekerja dua kali dalam bundel,
    Anda pasti harus melihatnya.

Selangkah demi selangkah

  1. Saya menyertakan raw-loader di package.json saya untuk dapat mengimpor file sebagai teks biasa.

    "raw-loader": "latest",
    
  2. Saya mengkonfigurasi Webpack sedemikian rupa sehingga pdf.worker.js dimuat melalui 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. Sekarang sampai pada bagian yang sulit. Satu-satunya cara untuk mengirimkan pekerja ke PDF.js adalah melalui pengaturan workerSrc . Sayangnya, melakukan hal-hal seperti

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

    tidak akan berhasil.
    TAPI! Kita dapat membuat URL dengan cepat dari Blob s, dan kita dapat membuat Blob s dari string dengan cepat!
    Jadi, solusi yang berhasil untuk saya adalah:

    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. Hanya satu lagi. PDF.js memiliki banyak fallback jika terjadi kesalahan saat memuat pekerja:
    js require.ensure([], function () { var worker; worker = require('./pdf.worker.js'); callback(worker.WorkerMessageHandler); });
    Jika Anda peduli dengan ukuran bundel dan menggunakan pdf.worker.min seperti yang saya lakukan, Webpack akan bingung dan tetap menyertakan pdf.worker.js karena hal ini. Yang lebih buruk lagi, bahkan versi PDF.js yang diperkecil meminta pdf.worker.js diperkecil. Jadi bagaimana kita bisa mengatasi omong kosong ini?
    Kami memberi tahu Webpack untuk mengganti satu modul dengan yang lain, seperti:
    js new webpack.NormalModuleReplacementPlugin( /pdf\.worker(\.min)?\.js$/, path.join(__dirname, 'node_modules', 'pdfjs-dist', 'build', 'pdf.worker.min.js'), ),
    yang memastikan bahwa setiap file yang cocok dengan /pdf\.worker(\.min)?\.js$/ - lebih khusus lagi, pdf.worker.js dan pdf.worker.min.js akan diganti dengan versi yang diperkecil.

Fiuh. Semoga ini bisa membantu siapa pun!

@wojtekmaj kami menambahkan pdfjs-dist / webpack untuk konfigurasi nol untuk pengguna webpack. Anda dapat melihat penggunaannya di https://github.com/yurydelendik/pdfjs-react

@yurydelendik Terima kasih, ya, saya mengetahui hal ini. Meskipun saya tidak berhasil membuatnya berfungsi sepenuhnya dan saya menghadapi banyak masalah karena berakhir dengan satu file yang dikompilasi adalah kebutuhan bagi saya.

Ini karena saya sedang mengerjakan react-pdf dan harus sangat mudah bagi pengguna saya untuk menginstalnya. package.json + import, boom, tidak ada yang lain.

Tidak mungkin saya bisa memberi tahu mereka untuk menggambar pdf.worker.js sendiri, apalagi menulis instruksi untuk webpack, browserify, dan yang lainnya.

harus sangat mudah bagi pengguna saya untuk menginstalnya. package.json + import, boom, tidak ada yang lain.

@wojtekmaj Saya tidak begitu mengerti kebutuhan Anda. Saya tidak melihat bagaimana menambahkan pdfjs-dist dan menggunakan pdfjs-dist / webpack tidak mungkin digunakan dalam proyek komponen react. Dan pengguna hanya akan memasukkan yang pertama (proyek komponen).

berakhir dengan satu file yang dikompilasi adalah kebutuhan bagi saya.

Satu file yang dikompilasi bukanlah yang Anda inginkan: a) untuk permulaan halaman, b) ukuran cache dan transmisi, c) kemungkinan masalah dengan pekerja - tetapi itu pilihan Anda.

@yuryelend
Oh, maaf, saya salah membaca posting Anda sebelumnya. Saya pikir Anda berbicara tentang / contoh / webpack yang merupakan hal yang sama sekali berbeda. Itu pasti harus diperbarui untuk menggunakan pdfjs / webpack! Terima kasih!

Satu hal lagi ... Menggunakan pdfjs-dist / webpack tidak menghentikan pdf.js itu sendiri dari mencoba meminta pdf.worker.js sendiri. Saya berakhir dengan:

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

Ketika saya mendefinisikan pdf.worker sebagai salah satu entri, itu menjadi lebih buruk , saya berakhir dengan:

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

Bagaimana cara memperbaiki masalah ini?

Setelah menjalankan yarn build dengan contoh react-pdf saya di atas, saya mendapatkan file berikut:

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

Itu normal: aplikasinya adalah barang 'build / static / js / main.5a79c9e3.js' (pdf.js plus react), 'build / static / js / 0.974e8de4.chunk.js' adalah pdf.worker.js kode fallback dimuat ketika pekerja dinonaktifkan dan kode pekerja 'build / 7b14afe24b211632ecc8.worker.js'. Apakah saya melewatkan sesuatu?

@wojtekmaj tolong siapkan komponen reaksi lengkap (contoh?) dengan aplikasi uji pengguna dan laporkan dalam masalah terpisah dengan STR - Saya pikir masalah khusus Anda tidak terkait dengan masalah ini.

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

tetapkan nilai seperti ini lalu kerjanya ...

Terima kasih...

Saat menggunakan solusi @yurydelendik, jika ada yang mendapatkan window tidak ditentukan kesalahannya

globalObject: 'true'

Di segmen output dari konfigurasi webpack Anda.
Sepertinya ada bug di webpack, webpack mengacaukan objek window saat bekerja dengan web workers . Jadi peretasan di atas menyelesaikan masalah itu.

@wojtekaj :
Terima kasih atas solusinya! Ini berfungsi dengan baik untuk saya di Chrome, FF, Edge, Opera, Safari. Tetapi karena Anda mengecualikannya dari babel-loader itu tidak ditranspilasi kembali ke ES5. Jadi saya mendapatkan masalah di IE11 dan seterusnya. Atau apakah saya melewatkan sesuatu di sana?

Saya mungkin melakukan sesuatu yang salah di sini, jadi tolong perbaiki oh orang pintar, tapi saya mengambil pemikiran @wojtekmaj , dan membuatnya bekerja jauh lebih sederhana.

Di webpack.config:

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

Dan kemudian, di kode saya:

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...

Konfigurasi:

  • pdfjs-dist: 2.1.266.0
  • webpack: 4.35.0

Hei, saya mengalami masalah saat menggunakan webpack dan pdfjs (dan itu pekerja).

Apa yang saya pikir itu terjadi (saya tidak tahu cukup pdfjs untuk memastikan apa pun)

Karena barang webpack, saya mengalami kesalahan ini saat mencoba memuat pekerja:

image

Saya tidak dapat menemukan apa pun untuk memperbaikinya.
vendor_pdfjsWorker ada tetapi tidak ada di jalur ini. Dalam kasus saya, saya ingin pekerja berada di tempat yang sama dengan pdf.js.
Awalnya saya mencoba mengubah workerSrc, seperti yang dijelaskan wojtekmaj. Tapi workerSrc saya tidak digunakan oleh pdfjs untuk mendapatkan pekerja. Pdfjs perubahan penguraian webpack (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;
  }

KE

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

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

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

Jadi, fakeWorkerFilesLoader disetel (l.9932):
fakeWorkerFilesLoader = useRequireEnsure ? function () {

Kemudian, workerSrc saya tidak mendapatkan penyebab fakeWorkerFilesLoader didefinisikan:

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

Bagaimana saya mengatasinya

Dalam konfigurasi webpack saya, saya menambahkan:

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

Dan kemudian saya mengalami kesalahan ini:
image

Ini memberi tahu saya bahwa skrip saya "ecm_viewer.worker.js" tidak ada.
Saya menambahkan entri di konfigurasi webpack saya:

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

Dan itu bekerja dengan sempurna, bahkan jika saya menghapus fungsi noParse. Saya tidak dapat men-debug kesalahan sebenarnya sampai saya menambahkan opsi webpack noParse ini.

Saya tidak tahu apakah saya di tempat yang tepat untuk menulis ini; Saya dapat memindahkan posting saya di stackoverflow atau di tempat lain. Ini dapat membantu seseorang suatu hari nanti.

Saya mengalami masalah yang sama dengan proyek webpack saya, tetapi saya menyelesaikannya secara berbeda. Alih-alih mengandalkan bundling atau pemuat webpack, saya menggunakan CopyWebpackPlugin untuk menyalin sumber pekerja ke direktori build saya.

Di penampil saya:

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

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

Ini memperbaiki masalah yang telah diburu tim saya selama WEEKS. Terima kasih @ctowler : D <3

Saat menggunakan solusi @yurydelendik, jika ada yang mendapatkan window tidak ditentukan kesalahannya

globalObject: 'true'

Di segmen output dari konfigurasi webpack Anda.
Sepertinya ada bug di webpack, webpack mengacaukan objek window saat bekerja dengan web workers . Jadi peretasan di atas menyelesaikan masalah itu.

@vivektiwary Saya mengalami masalah yang sama. Itu terus mengatakan ReferenceError: Can't find variable: window

Saya memang memasukkan pengaturan globalObject:'true' di file Webpack.config tetapi aplikasi sekarang tidak mau memuat sama sekali. Apakah Anda yakin itu berhasil?

Saat menggunakan solusi @yurydelendik, jika ada yang mendapatkan window tidak ditentukan kesalahannya

globalObject: 'true'

Di segmen output dari konfigurasi webpack Anda.
Sepertinya ada bug di webpack, webpack mengacaukan objek window saat bekerja dengan web workers . Jadi peretasan di atas menyelesaikan masalah itu.

@vivektiwary Saya mengalami masalah yang sama. Itu terus mengatakan ReferenceError: Can't find variable: window

Saya memang memasukkan pengaturan globalObject:'true' di file Webpack.config tetapi aplikasi sekarang tidak mau memuat sama sekali. Apakah Anda yakin itu berhasil?

Ya @taihuuho , apakah Anda memasukkannya ke dalam
btw apa kesalahan yang Anda dapatkan?

@vivektiwary Saya mendapatkan kesalahan ini ReferenceError: Can't find variable: window saat menggunakan pdfjs-dist/webpack

Saya mungkin melakukan sesuatu yang salah di sini, jadi tolong perbaiki oh orang pintar, tapi saya mengambil pemikiran @wojtekmaj , dan membuatnya bekerja jauh lebih sederhana.

Di webpack.config:

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

Dan kemudian, di kode saya:

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...

Saya akhirnya menggunakan solusi @varunarora dan itu bekerja dengan sangat baik. Rupanya, halaman dokumentasi untuk Webpack https://github.com/mozilla/pdf.js/tree/master/examples/webpack tampaknya tidak berfungsi untuk semua orang

Tanpa perlu mengedit konfigurasi webpack:

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

atau

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

PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;

dan tentu saja pastikan Anda telah menginstal file-loader .

Saya menggunakan electron-forge yang menyebabkan file-loader meletakkan pekerja di direktori jadi saya harus menggunakan

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

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

Menggunakan file-loader entah bagaimana memiliki efek samping pada aplikasi saya lainnya, karena librariries lain membutuhkannya. Jadi cara lain yang saya temukan adalah dengan mendapatkan file pdf.worker.js dari cdn:

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

Apakah halaman ini membantu?
5 / 5 - 1 peringkat