mirror of
https://github.com/zen-browser/pdf.js.git
synced 2025-07-09 01:35:43 +02:00
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1] In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2] One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting. Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3] This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result. One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4] --- [1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility [2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is. [3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general. [4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
This commit is contained in:
parent
0a970ee443
commit
927e50f5d4
23 changed files with 227 additions and 241 deletions
|
@ -51,7 +51,6 @@ import {
|
|||
DOMStandardFontDataFactory,
|
||||
isDataScheme,
|
||||
isValidFetchUrl,
|
||||
loadScript,
|
||||
PageViewport,
|
||||
RenderingCancelledException,
|
||||
StatTimer,
|
||||
|
@ -1986,14 +1985,13 @@ const PDFWorkerUtil = {
|
|||
fakeWorkerId: 0,
|
||||
};
|
||||
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
|
||||
// eslint-disable-next-line no-undef
|
||||
if (isNodeJS && typeof __non_webpack_require__ === "function") {
|
||||
if (isNodeJS) {
|
||||
// Workers aren't supported in Node.js, force-disabling them there.
|
||||
PDFWorkerUtil.isWorkerDisabled = true;
|
||||
|
||||
GlobalWorkerOptions.workerSrc ||= PDFJSDev.test("LIB")
|
||||
? "../pdf.worker.js"
|
||||
: "./pdf.worker.js";
|
||||
: "./pdf.worker.mjs";
|
||||
}
|
||||
|
||||
// Check if URLs have the same origin. For non-HTTP based URLs, returns false.
|
||||
|
@ -2126,11 +2124,7 @@ class PDFWorker {
|
|||
);
|
||||
}
|
||||
|
||||
const worker =
|
||||
typeof PDFJSDev === "undefined" &&
|
||||
!workerSrc.endsWith("/build/pdf.worker.js")
|
||||
? new Worker(workerSrc, { type: "module" })
|
||||
: new Worker(workerSrc);
|
||||
const worker = new Worker(workerSrc, { type: "module" });
|
||||
const messageHandler = new MessageHandler("main", "worker", worker);
|
||||
const terminateEarly = () => {
|
||||
worker.removeEventListener("error", onWorkerError);
|
||||
|
@ -2312,40 +2306,15 @@ class PDFWorker {
|
|||
// Loads worker code into the main-thread.
|
||||
static get _setupFakeWorkerGlobal() {
|
||||
const loader = async () => {
|
||||
const mainWorkerMessageHandler = this.#mainThreadWorkerMessageHandler;
|
||||
|
||||
if (mainWorkerMessageHandler) {
|
||||
if (this.#mainThreadWorkerMessageHandler) {
|
||||
// The worker was already loaded using e.g. a `<script>` tag.
|
||||
return mainWorkerMessageHandler;
|
||||
return this.#mainThreadWorkerMessageHandler;
|
||||
}
|
||||
if (typeof PDFJSDev === "undefined") {
|
||||
const worker = await import("pdfjs/pdf.worker.js");
|
||||
return worker.WorkerMessageHandler;
|
||||
}
|
||||
if (
|
||||
PDFJSDev.test("GENERIC") &&
|
||||
isNodeJS &&
|
||||
// eslint-disable-next-line no-undef
|
||||
typeof __non_webpack_require__ === "function"
|
||||
) {
|
||||
// Since bundlers, such as Webpack, cannot be told to leave `require`
|
||||
// statements alone we are thus forced to jump through hoops in order
|
||||
// to prevent `Critical dependency: ...` warnings in third-party
|
||||
// deployments of the built `pdf.js`/`pdf.worker.js` files; see
|
||||
// https://github.com/webpack/webpack/issues/8826
|
||||
//
|
||||
// The following hack is based on the assumption that code running in
|
||||
// Node.js won't ever be affected by e.g. Content Security Policies that
|
||||
// prevent the use of `eval`. If that ever occurs, we should revert this
|
||||
// to a normal `__non_webpack_require__` statement and simply document
|
||||
// the Webpack warnings instead (telling users to ignore them).
|
||||
//
|
||||
// eslint-disable-next-line no-eval
|
||||
const worker = eval("require")(this.workerSrc);
|
||||
return worker.WorkerMessageHandler;
|
||||
}
|
||||
await loadScript(this.workerSrc);
|
||||
return window.pdfjsWorker.WorkerMessageHandler;
|
||||
const worker =
|
||||
typeof PDFJSDev === "undefined"
|
||||
? await import("pdfjs/pdf.worker.js")
|
||||
: await __non_webpack_import__(this.workerSrc); // eslint-disable-line no-undef
|
||||
return worker.WorkerMessageHandler;
|
||||
};
|
||||
|
||||
return shadow(this, "_setupFakeWorkerGlobal", loader());
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue