Pdf.js: Using pdfjs-dist/webpack results in pdf.worker.js imported twice

[wojtekmaj]

I am trying to use PDF.js in my project, react-pdf.

Following @yurydelendik (undocumented?) recommendation I've used pdfjs-dist/webpack to import PDF.js into my project.

Here's the outcome:
https://github.com/wojtekmaj/react-pdf/tree/import-pdfjs-using-webpack

Very simple source is located at ./sample
Output is at ./sample/build

I've analyzed the result using webpack JSON stats.
From that I realized that pdf.worker.js is imported twice.
One is 8d94cec765cddcb66c2d.worker.js file. This is the one that is correctly loaded and used.
What you can see though is a second, 0.bundle.js file. This bundle contains a second copy of pdf.worker.js, as pdfjs-dist/build/pdf.js requests for it, but this time without 'worker-loader!' prefix.
I understand why the bundle itself is needed, but I don't think that we should export the same code twice, wrapped differently.

So my question is: If Workers are not supported by the browser and 0.bundle.js is loaded, how does pdf.worker.js benefits the user?

Edit: After getting bigger understanding of how it works, I know that pdf.worker.js is a file we need, while 0.bundle.js is a "trash" bundle that never gets loaded.

[mihaislobozeanu]

Hi,

I don't know if it is too late. You can avoid this by using IgnorePlugin. here is the updated webpack.config

var webpack = require('webpack');
var path = require('path');

module.exports = {
    context: __dirname,
    entry: {
        'main': './main.js',
        'pdf.worker': 'embed-pdfjs-dist/build/pdf.worker.entry'
    },
    output: {
        path: path.join(__dirname, '../../build/webpack'),
        publicPath: '../../build/webpack/',
        filename: '[name].bundle.js'
    },
    plugins: [
        new webpack.IgnorePlugin(/^\.\/pdf.worker.js$/),
        new webpack.optimize.UglifyJsPlugin({
            compressor: {
                screw_ie8: true,
                warnings: false
            }
        })
    ]
};

[wojtekmaj]

Thanks!
Normally that would be a good solution, but not if you would like to provide users with zero-config bridge between React and PDF.js for your users, like me ;)

[mihaislobozeanu]

Anyway, it seems that my solution does not work properly. As far as I can see, they have to support browser without worker and this is the reason they import it with require. As designed, workers do not accept objects for initialization. An workaround would be to provide the entire pdf.worker.js content as string, but I don't know how to do that and in the same time to pass it where they import it with require ... yet. I'm in the same situation as you are. Luckily for me, I have three months to come up with a solution :).

[wojtekmaj]

Actually, I believe the problem is that we're using two separate loaders on the same file, which confuses webpack. As a result, it creates two copies of pdf.worker.js, one wrapped in a Worker and one not wrapped.
If we imported the file in the same way in both cases, and then wrapped the file in a Worker by ourselves (seems like it's an easy process), then the problem would be gone.

[saimanoharnethi]

Did we arrive at a solution for this? @wojtekmaj , I am using the react-pdf lib and wondering if this is solved or if I am still encountering this in my code. Also, I was wondering if there is a way to package the pdf.worker.js together and produce one pdf-viewer.js file without importing it dynamically or is that what browser web workers do?

My specific use case is I am building little widgets that my larger application (lot of legacy code here) can dynamically load. My pdf-viewer-widget.js is a wrapper(HOC) around react-pdf, whose only job is to determine which pdf to load based on props passed to it. When loading the pdf-viewer widget, I dont want it to request additional js resources (pdf.worker.js) dynamically because the container application has a baseHref which messes with the request url.

Is there a way to package it in and avoid dynamic loading?

Thank you!

[wojtekmaj]

You can work around this by copying pdf.worker.js manually to your dist folder instead of using Webpack-specific entry file. Webpack worker-loader can't work around this and creates two copies - although will use only one of them, so it doesn't affect the end user. Perhaps new worker-loader for Webpack 4 will be smarter.

[timvandermeij]

Closing since we've changed the way we're working with Webpack to remove those dependencies from pdfjs-dist. None of is is experienced with Webpack, so we decided to make the example more self-contained to reduce maintenance.