react-pdf
react-pdf copied to clipboard
Support React 17
NPM v7 throws the following error when using react-pdf with the latest version of React
npm ERR! node_modules/react
npm ERR! react@"^17.0.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer react@"^16.0.0" from @react-pdf/[email protected]
npm ERR! node_modules/@react-pdf/renderer
npm ERR! @react-pdf/renderer@"^1.6.10" from the root project
I'm not sure if there are any code migration required or if only the package.json
needs to me modified.
Any update on this?
Interested too
it might help you npm install @react-pdf/renderer --legacy-peer-deps
it might help you
npm install @react-pdf/renderer --legacy-peer-deps
This is a quick fix that solves the situation temporary, but if you remove the lock file, you have to use it again. It is not a clean solution...
Made a pull request to bump react version here: https://github.com/diegomura/react-pdf/pull/1157
You can meanwhile just fork this and issue npm update react
, it works fine and then all tests pass, not sure where any maintainers are on this one, the original React 17 version issue was raised last October...
Hi! Sorry for the delay! What would happen to projects using React 16? Don't have much time to test right now but I'd love to merge this asap
@diegomura Maybe you can add both, with version range, until you test it.
So I tried upgrading react's peer dependency from ^16.8.6
to >16.8.6
that matches new React 17 version, but NPM v7 stills throws peer dependency errors due to [email protected]
which has react@16
as peer dependency as well...
The newest [email protected]
has react@^17.0.0
as peer dependency, but if I'm not mistaken will break react-pdf to anyone using react@16
, which is still a lot of people (EDIT: I tried this, and it does break things to people using react@16
)
It seems that the cause of this is NPMv7 now installs peer dependencies and breaks things (this is apparently breaking the react library ecosystem, not just this package). I'm open to suggestions here but I do not see how I can keep supporting all react versions and making NPMv7 to work, unless you use the --legacy-peer-dep
flag as recommended above.
For those blocked by this, it is not that you cannot use the lib with React17 and NPM7, it jus throws this error when installing
Just published 1.6.16
with the change suggested by @princefishthrower above, but I think it's not enough to make this whole peerDependency check to work. Please try it and let me know!
@diegomura I tried on 2.0.0 and 1.6.16, but unfotunately it doesn't work without --legacy-peer-dep flag
Yes. As explained above, I couldn't find the way of keep supporting react 16 and 17. This whole peer dependency check in nvm@7 breaks this library. The issue is not just react-pdf peer dependency but specially react-reconciler
peer dependency as well. If I define both react-reconciler versions on our side, npm still does not infer the correct version it has to use. I'm open to suggestions here
Hi @diegomura
I see the problem. Maybe solution with aliases could help in this case? https://dev.to/joshx/test-your-npm-package-against-multiple-versions-of-its-peer-dependency-34j4
Interesting.. But I don't think npm aliases can solve this. I will still have to list a react-reconciler
version with a peer dependency of react@16, so the check will still fail, right?. I thought that by defining "react-reconciler: ^0.23.0 || ^0.26.0"
npm would automatically choose the version who's peer dependencies best adjusts to your dependencies (0.23.0 having react@16 and 0.26.0 react@17 respectively). But no, it always end up installing 0.26.0, breaking all those projects that uses react@16.
React official renderers builds, such as react-dom or react-native, are shipped with the react-reconciler
code embedded in the build (I mean, not as an external dependency). This is something I guess I can do for this project as well, although it just feels wrong to publish this package with a third-party dependency built inside of it
Hi @diegomura
React official renderers builds, such as react-dom or react-native, are shipped with the react-reconciler code embedded in the build (I mean, not as an external dependency). This is something I guess I can do for this project as well, although it just feels wrong to publish this package with a third-party dependency built inside of it
I think it's a good point.
Interesting.. But I don't think npm aliases can solve this. I will still have to list a react-reconciler version with a peer dependency of react@16, so the check will still fail, right?. I thought that by defining "react-reconciler: ^0.23.0 || ^0.26.0" npm would automatically choose the version who's peer dependencies best adjusts to your dependencies (0.23.0 having react@16 and 0.26.0 react@17 respectively). But no, it always end up installing 0.26.0, breaking all those projects that uses react@16.
Maybe I'm completely wrong, but I have an assumption why npm always installs latest minor version, probably because ^0.23.0
is equivalent to ^0.26.0
?
What if to try something like "react-reconciler: 0.23.0 || ^0.26.0"
Thanks @maxdev ! That might be right. Will try today and report back here
Unfortunately this still happens :(
npm keeps insisting on installing [email protected]
even if react@16
is present
I can confirm that it is still broken
Thanks @KarlBaumann. It is :( but as explained above I'm on a dead end for both supporting react 16 and 17 with the new npm peer dependency install
@diegomura I would say you don't have to support outdated libraries in latest versions. If people want to use outdated software, they can use older releases.
While I generally agree, with React for me it's more complex. Since it's the main peer dependency of this project and one of those libraries that people usually do not update right away, just stopping support for React 16 would leave many people behind. It's not that people using React17 cannot use latest build either. For what I understood, the only issue is with the latest npm peer dependency check, right?
for me it does not work also with the peer-dependency-check disabled. It is totally normal that major releases introduce breaking changes. Thats why I would expect that everyone who is already using the library, has something like this ^2.0.0 in their package.lock file, so your version 3 would not break their apps.
Just curious, how long do you forsee supporting React 16?
I don't have any fixed plan. I'm open to suggestions π Would still love to see if there's some solution to this. @KarlBaumann releasing a 3.x it's not an option since that would be even more confusing
Is it possible to use a βorβ condition ?
"react": "^16.0.0 || ^17.0.0",
"react-dom": "^16.0.0 || ^17.0.0",
+1
also looking for react-17 support
How difficult would it be to create a React 17 compatible version as a temp measure for those of us on React 17? i.e. leave 16 as the main supported version it's time for the whole thing to officially move to be based on React 17?
1+. This library seems super useful and our team would like to use it in our production application to generate a PDF and download it. We use React 17 however and there aren't many other alternatives that provide a solution to this :(
I think making a separate version for React 17 and one for React 16 would be a good way to temporarily solve this issue as mentioned by @grmatthews.
Waiting for React 17 support
Waiting for React 17 Support, Planning to use this lib in our production env
Any update here? @diegomura