Cannot specify web worker src location (specifically prevents use of PDF.js)

[draperd]

This issue has been generated from a comment by @gaearon in #1015. This issue will probably want to be labelled as a discussion. The objective of raising this issue is to capture a real-world use case to be resolved.

Essentially my objective is to be able to use PDF.js in my application. In order to do this I need to be able to configure the workerSrc attribute on the PDFJS global object.

The recommended approach (as described in this example) is to add a new entry into the webpack configuration so that a new bundle will be generated (just containing the worker source) and then pass a relative path to that bundle.

i.e. in webpack.config.js

  entry: {
    'main': './main.js',
    'pdf.worker': 'pdfjs-dist/build/pdf.worker.entry'
  },

then when using PDF.js

var pdfjsLib = require('pdfjs-dist');

// Setting worker path to worker bundle.
pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js';

Unfortunately #1084 deals with the requirement to add additional entries (which at the time of writing is still unresolved). I've raised this as a separate issue because although there is some overlap the is a specific requirement here to enable relative paths to JS files to be specified that can still be resolved as individual files after build.... adding additional entries is one solution, but is entirely dependent upon webpack and my understanding is that a more generic solution (not specific to webpack) is required.

I've explored some other solutions (like using file-loader as described for this project) and have also explored using require.ensure.

[gaearon]

Thanks for raising this! It’s an interesting use case. We’ll keep this in mind when we consider supporting multiple entries.

[Timer]

Sorry for the fly-by, but I use PDFJS successfully in my react-scripts application by just requiring pdfjs-dist/build/pdf.combined.js.

Please don't mind the mess, this code is a year or so old (though in production!).

https://gist.github.com/Timer/25401841c527ee5b7672fefba236e35d

Used like so:

            <div className="row text-center">
              <div className="col-xs-6">{top ? <PDFView width={width / 2} height={height} file={`${origin}/api/pdfs/${top}`} /> : null}</div>
              <div className="col-xs-6">{bottom ? <PDFView width={width / 2} height={height} file={`${origin}/api/pdfs/${bottom}`} /> : null}</div>
            </div>

[draperd]

@Timer My understanding of pdf.combined.js is that it doesn't use web workers (effectively it disables them). This means that large PDFs will take a really long time to render. You can for example just specify a false path for the workerSrc and it will have the same effect. However I want to try and get the best performance out of PDF.js so want to use web workers.

[Timer]

Fair enough @draperd, in my experience renders are pretty quick except for on raspberry pis... If you're showing the same PDF over and over that component does cache the PDF after first render so it never has to do so again.

I was just trying to give you a temporary solution until we can work out something more permanent. :)

[draperd]

My temporary workaround at the moment is just to point to provide a web hosted location (i.e. "http://mozilla.github.io/pdf.js/build/pdf.worker.js") as this will always work, but we want to be able to provide a solution inside the firewall where access to the outer internet is not allowed. We're also looking at dealing with fairly substantial PDF files with many pages and you tend to notice the slow-down quite quickly.

[draperd]

Another option I've just realised is to copy the worker source file to the public folder and reference is like this:

window.PDFJS.workerSrc = process.env.PUBLIC_URL + "/pdf.js/build/pdf.worker.js";

This also seems to work within the application, but for my specific use case (I'm using create react app as a development environment to build re-usable components that I'm then publishing to NPM) this won't work.... but as a solution just within create react app this would definitely work.

I'm happy to close this issue as my specific requirements are almost certainly outside the scope of this project.

[gaearon]

OK. I'll close in favor of a more generic #1277.

[kellyrmilligan]

just wanted to comment on this, this is a little tricky if your CRA is behind a proxy as part of a larger app. in development, public url is not the sub path :( . hopefully serve-app-under PR and the dependent webpack-dev-server PR will get some traction.

[jesusgp22]

@draperd I've been trying just about everything and I didn't get to load the worker even with your solution

[draperd]

@jesusgp22 I've not looked at this for quite a while as I switched company so this no longer became an issue for me... unfortunately I don't have access to the project where I had this all setup so I can't really help unfortunately :(

[cs-NET]

I have managed to work around this issue by using worker-loader directly:

$ npm install worker-loader --save-dev

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

PDFJS.GlobalWorkerOptions.workerPort = new PDFJSWorker();
const loadingTask = PDFJS.getDocument(url);