-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
React-PDF Unusable For Modern Packaging Systems & Server Side Rendering #2624
Comments
Good point. We should have an additional
Huh? Well, setting "type": "commonjs" is also not accurate because the package could be used as ESM. "type": "module" tells tools like bundlers and Node.js how .js files should be treated. And all files except for .cjs ones are ESM. So with my current state of knowledge I'd disagree with you.
See above. I don't think that should be necessary. Regarding Next.js problem - starting with Next.js 14.1.1, on App Router, I've seen no issues with PDF rendering, so that's a good start I think.
Yeah, I agree, that's a complicated part. How we could provide usePDF for Next.js SSR? |
Completely, I don't think As an example, here is what
Yes, but that isn't the issue. For environments that have no understanding of ES Modules they could still attempt to load the
I think it is more a question of what are you protecting against? If you purely look at What I didn't include above is that in addition to the resolutions I had to patch So I would do two things:
I look at the two implementations and I don't see anything that isn't available in both environments. Maybe change There could be other aspects that I am missing which may prevent this, and this is exclusively related to |
Thanks @wojtekmaj and @jd-carroll for all the thoughts here! Criticisms were taken with ❤️. My only comment, if I might, is that the "unusable" part of the issue title is a bit unfair as I'm running current versions with latest vite on the examples package, and NextJS for the docs website 😄 Having said that haha, let me comment bit by bit
Agree, but after reading docs, shouldn't be more like this?
I'm with @wojtekmaj here. I don't really see how it changes considering conditional exports are in place. From docs: The preceding example uses explicit extensions .mjs and .cjs. If your files use the .js extension, "type": "module" will cause such files to be treated as ES modules, just as "type": "commonjs" would cause them to be treated as CommonJS So I rather have them as
I'm very much aware of the issues here. It's just something I never had time thinking and working on. But it's still possible to use it by disabling SSR around the react-pdf components as the REPL does. Tbh SSR PDFs using About points above:
|
@wojtekmaj 14.1.1 isn't even out yet; it's on Canary. I've installed the latest Canary version, which is 14.1.1-canary.77, and it doesn't work. |
I tried something like below because the version 3.1.14 of renderer doesn't contain a fix we need, but I can't make 3.3.8 work. Is it impossible for now ?
Still having errors like |
Are there any udpates here? |
Bump, would love to see this fixed! |
bump |
we ran into an issue upgrading to 9.10 in our React/GraphQL app Here was our fix in config-overrides.js webpack export:
if anyone has a better idea or thoughts lmk |
Bump for the fix please curious to know 💯 |
There are multiple issues here, please read carefully. This should probably be broken into multiple issues but consolidating here to keep it simple for me.
The issues described here will also resolve: #2599 & #2623
React-PDF Unusable for Modern Packaging Systems
This one is a little frustrating, please take some time to read the documentation for how ESM modules work:
https://nodejs.org/api/packages.html#package-entry-points
TLDR;
The current
exports
of@react-pdf/renderer
has no browser entry making it impossible for a project which respects ESM modules to work in the browser.Additionally, if you're going to bundle both CommonJS and ES Module files in the same package, please use
.mjs
file extensions. Setting"type": "module"
in the package isn't exactly accurate because the package could be used as a CommonJS package and not just an ES Module. More importantly, if you're going to continue to use.js
file extensions, please reserve that for the CommonJS files.Here is what I think you should target in
@react-pdf/renderer/package.json
Note: While I only documented it for
@react-pdf/renderer
, this would be required for every package.React-PDF Unusable for Server Side Rendering
This one is a little more complicated and will require actual changes in the code.
In short, when using a server side rendering framework like NextJS your code is run twice, once on the server to generate a (typically) reusable [pre]rendered page which is served for incoming requests. The second is in the browser where the code is actually running for its intended purpose.
If you look at the generated output from a NextJS build, you will actually see two different bundles:
server/chunks
-> Used for running on the server to generate the pre-rendered pagestatic/chunks
-> Served to the client for running in the browserThe problem
When NextJS builds the bundle for
server/chunks
it uses the default conditions of["node", "import"]
Therefore the server side bundle will always receive the node version of the package causing legitimate uses (eg.
usePDF
) of the package to break.To be honest, it also seems to me that you are abusing the
"browser"
convention of bundlers. You are not providing an "alternate" implementation targeted for the browser environment, you are providing a completely different implementation.Further, if I wanted to render the PDF to a stream or buffer on the browser, why are you preventing me? If I needed to send the PDF to the server, that is exactly what I would look to do.
Work Arounds
If you are landing on this issue and think it pertains to you, there are no work arounds.
Your only solution (for now) is specifying resolutions for all packages under
@react-pdf
Final thought:
diegomura wojtekmaj - Thank you for creating this module, it is actually pretty useful. All criticism with ❤️
The text was updated successfully, but these errors were encountered: