pdf.js: 4.0.189: Top-level await is not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari14" + 2 overrides)

Solved by adding vite configuration:

optimizeDeps: {
    esbuildOptions: {
        target: "esnext",
    },
},

And if i’m working in Angular project that’s been created with Angular CLI (NO VITE CONFIGURATION FILE !), what should i do ?

How to solve this issue with projects that does not based on vite ?

this should be the final answer

{
  build: {
    target: "es2022"
  },
  esbuild: {
    target: "es2022"
  },
  optimizeDeps:{
    esbuildOptions: {
      target: "es2022",
    }
  }
}

this fixed it for me, thank you!

this should be the final answer

{
  build: {
    target: "es2022"
  },
  esbuild: {
    target: "es2022"
  },
  optimizeDeps:{
    esbuildOptions: {
      target: "es2022",
    }
  }
}

I totally agree with @JHarrisGTI. pdf.js would totally also work without top-level await. Please provide us a version of it which is compatible with the compilers of all big frameworks, including Angular!

Note: The reason that we went with top level await in the re-factoring for PDF.js version 4 was to reduce complexity.

It should be possible to remove top level await from the PDF.js builds, and I’ve even got WIP patches locally. However doing so would increase code complexity, and thus add to the maintenance burden, of the general PDF.js library and basically cause the (unpaid) core contributors more work.

If you’d like to see top level await be removed from the builds and are serious about paying for that be implemented, please contact me privately. (Email address can be found in my GitHub profile.)

Please keep in mind that the primary development target of this library is the Firefox PDF Viewer, and the fact that the general PDF.js library can still be used elsewhere is thanks to a lot of time/effort spent by a few unpaid contributors (such as myself) over the years. This is work that no-one is sponsoring and many users don’t even bother saying thank you, however a few users seem all too willing to essentially complain about something that’s provided for free. For example, comments such as the following seem uncalled for and are quite disheartening to read:

But at the same time, nowadays it is more common to just ‘take and use’ and when some package requires complicated setup it looks like something from 90s.

@Snuffleupagus I’m definitely interested in having that fixed as a lead maintainer of React-PDF. Please kindly submit $50 expense on https://opencollective.com/react-pdf-wojtekmaj 😃

@yuri-apanasik What do you mean “on the client side”? You used pdf.js in browser or node environment?

If you use it in browser, all you need is comment out two lines code, and run gulp task dist-pre, the result will not contain the top level await.

You can also change the two files to flatten and replace the await __non_webpack_import__ with directly import under some if inNodeJS statement.

https://github.com/mozilla/pdf.js/blob/833d7ac8303c9002a65911efa6dd4dea4d127db6/gulpfile.mjs#L305

    // line 305, 306
    // libraryAlias["display-node_stream"] = "src/display/node_stream.js";
    // libraryAlias["display-node_utils"] = "src/display/node_utils.js";

Export pdfjsLib as follows:

import * as pdfjsLib from "pdfjs-dist";
import * as pdfWorker from "pdfjs-dist/build/pdf.worker.mjs";

// Setting worker path to worker bundle.
pdfjsLib.GlobalWorkerOptions.workerSrc = pdfWorker;

export { pdfjsLib };

I’m also struggling with this issue. I upgraded my Angular project to pdf.js v4, struggled with Angular’s build system, got it working. Now I’m upgrading Angular from 17.0 to 17.2 and Angular is giving me warnings about using topLevelAwait again.

Angular says they do not support top-level await. That means that developers have to either a) arm-wrestle the Angular compiler into something it’s not meant for, b) hack together a custom build of pdf.js as @yuri-apanasik has attempted to do, or c) stay on an old version of pdf.js until that eventually stops working.

I keep solving this issue and then having to re-solve it every time I upgrade a piece of my project. Top-level await has been described in this thread as a “stable JavaScript feature”, and that may be true according to the specification, but compiler support for that feature is not yet widespread enough to provide a stable experience. Angular provides two new build systems with v17; neither one supports this feature.

@Priestch I mean in browser, yes. Thank you one more time for the hint! We’ll try to make our own pdfjs build. But as you can see it is not only my problem, a lot of developers who want to easily use pre-built package face with this problem. One of the minimal ways to reproduce is:

• create new Angular app ‘ng new app-test-pdfjs-dist’
• install pdfjs-dist ‘npm i pdfjs-dist’
• add any import ‘import { getDocument } from ‘pdfjs-dist’’ and mention ‘getDocument’ somehow, so import is not ignored by bundler

Result -> build failed. As you suggested situation can be fixed with custom build, but it makes ‘pdfjs’ minimal usage example more complicated. After we fix the issue with custom build we’ll probably prepare short blog post, but later, now we are ok with v3 for PoC version.

@Priestch yes, I am new in pdf.js, we just looked for the tool to convert PDF to PNG on the client side and found pdf.js. So, as lazy developers we just took pre-built ‘pdfjs-dist’ package and faced with bundler issue. For now we are on PoC phase, so as a solution we just downgraded ‘pdfjs-dist’ to V3. For the production looks like we should go with custom build solution. Thank you for the suggestion! But at the same time, nowadays it is more common to just ‘take and use’ and when some package requires complicated setup it looks like something from 90s. Especially when there is no special tooling to apply all configuration with one magical command. It is a joke (partly), but it would be nice if you can provide some examples in the pdfjs docs about custom builds in different cases.

Can we get this issue reopened ? This has not been resolved yet.

@yuri-apanasik That is exactly what I was afraid of - more issues when making custom build.

The reason we wanted to update to v4 is that we had one incident with pdf badly rendered - some border was misplaced. Could not reproduce it unfortunately, so now we are waiting and keeping an eye for such errors.

@Priestch Just for information… I’ve tried to make custom pdfjs build, there were some troubles: for example, ‘node-canvas’ have no arm64 build, so had to solve this issue for M1. Finally pdfjs was ok, but unfortunately when I copied result files into the project and build (actually build was also successful) I faced with error in runtime (some class used before its declaration). I think it is not ‘pdfjs’ problem, more likely it is webpack glitches, but with the team we decided not to spend more time on this and stay with ‘pdfjs’ V3. I don’t believe it is only some people from this issue who faced with ‘top level await’ incompatibility and didn’t upgrade to V4 because of that. So, probably, you can at least discuss in your team this question and measure the necessity of using ‘top level await’ feature.

@yuri-apanasik - yep, im just doing it - but v4 changes the location of workers and my app needed them I think. So trying to somehow work that out.

export 'default' (imported as 'pdfjsWorker') was not found in 'pdfjs-dist/build/pdf.worker.mjs' (possible exports: WorkerMessageHandler)

I wouldnt mind that custom build, we could host it. But I dont want to waste time reading how to do it. As you said in one of your comments its like in the 90s -here is kernel, now code build yourself an OS to write play asteroids or sth… Aint nobody got time for that.

Any chance someone posts how to prep whole build?

For reference our usage is for example: - I am not even sure if we need the workers

if (!GlobalWorkerOptions.workerSrc) {
      GlobalWorkerOptions.workerSrc = pdfjsWorker;
    }
    return new Response(file)
      .arrayBuffer()
      .then(
        async (data: BinaryData) =>
          getDocument({ data, verbosity: 0 } as DocumentInitParameters)
            ?.promise,
      )
      .then(async (doc) => {
        const numPages = doc.numPages;
        await doc.destroy();
        return numPages > attachmentPageLimit;
      })
      .catch((e) => {
        if (e.name !== 'PasswordException') {
          throw new Error(e);
        } else {
          throw new JsPdfLibError(this.corruptOrPwdProtectedMessage, e);
        }
      });

I don’t agree this is an issue with Angular. The v3 works for us for now but we had some badly rendered pdfs lately and want an upgrade. The only v3 that worked so far was 3.8.162 due to svg typings issues. We only use basic rendering so never dug deep enough to understand this library. Both builders in angular produce some errors, the common one being this top-level-await. While I understand Angulars position (zone.js etc), I don’t know pdf.js enough to understand forcing incompatible builds.

Moreover - there is this legacy build available yet somehow it can’t be imported - when building the app it throws not found errors.

We are running out of ideas how to workaround the workaround.

This seems like a bug in angular, if a default angular app crashes when using a stable JavaScript feature. It’s like saying “please don’t use classes because Angular has a bug and doesn’t support them”.

Agree with @farisshomali, angular out-of-the-box uses Webpack, there is possibility to customize its configuration with (experiments: { topLevelAwait: true }), but it means stick to webpack (not good). Trying to use ‘esbuild’ (planned to be used by Angular out-of-the-box) and pdfjs - build fails (‘esbuild’ has no intention to support toplevelawait’ at all). So, question is can ‘top level await’ be avoided by ‘pdfjs’? It will make it easier to use any bundler.

For anyone wanting broader browser support - https://www.npmjs.com/package/vite-plugin-top-level-await.

{
// vite.config
plugins: [
    // ...
    topLevelAwait({
      promiseExportName: '__tla',
      promiseImportName: i => `__tla_${i}`,
    }),
  ],
}

Note: Bundle size will be 30kb larger compared to native es2022.