Skip to content

[Feature]: Add package exports #19963

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Radiergummi opened this issue May 21, 2025 · 3 comments
Open

[Feature]: Add package exports #19963

Radiergummi opened this issue May 21, 2025 · 3 comments

Comments

@Radiergummi
Copy link

Is the feature relevant to the Firefox PDF Viewer?

No

Feature description

It would be nice if the pdf.js package would define Package Exports in its package.json file. In essence, this allows to specify both which modules (or files) can be imported from a package depending on the runtime environment.
This would make it a lot easier to load pdf.js in a variety of situations, such as Node.js, webpack, or modern browsers, which right now all require different workarounds (like importing from the legacy/ folder, or setting the worker src, and so on).

Without further research, the exports for pdf.js might look like this:

"exports": {
  ".": {
    "import": "build/pdf.mjs",
    "require": "legacy/pdf.min.mjs",
    "browser": "build/pdf.min.mjs",
    "worker": "build/pdf.worker.min.mjs",
    "types": "types/src/pdf.d.ts",
    "node": "legacy/pdf.mjs",
    "webpack": "webpack.mjs"
  },
  "./viewer": {
    "import": "web/pdf_viewer.mjs",
    "styles": "web/pdf_viewer.css",
    "types": "web/pdf_viewer.d.mts",
    "require": "legacy/web/pdf_viewer.mjs"
  }
}

With exports defined, the package as installed from npm would allow two exports:

  • import ... from 'pdfjs-dist';
  • import ... from 'pdfjs-dist/viewer';

The source file the above import statement resolves to depends on the runtime environment. This could be a lot more granular and I'm sure I made some wrong assumptions above, since I'm not very familiar with the code base.
I just wanted to bring this up as a possible ergonomics improvement here.

Other PDF viewers

No response

@Snuffleupagus
Copy link
Collaborator

The "problem" is that something like this would further increase the maintenance burden of the pdfjs-dist package, for a feature that's not needed in the Firefox PDF Viewer.

@Radiergummi
Copy link
Author

I would argue that it'd reduce the issue load from people who encounter import problems, but I certainly see your point. Feel free to close if this doesn't seem right.

@Radiergummi
Copy link
Author

In case a maintainer wants to pick this up, or someone is interested in getting it to work on their end: I created my own wrapper package with properly configured conditional package exports here:

https://github.com/colibri-hq/colibri/tree/next/packages/pdf

It isn't published yet, but the code should be fairly straightforward to understand. Basically, there's separate exports for pdf.js, the viewer, and the sandbox; all of them support being imported from the browser or Node.js and will resolve to the correct module code automatically. When running in a browser, the worker source URL will also be set automatically at runtime.
So this reduces the code required to using pdf.js anywhere down to import pdf from '@your-ns/pdf'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants