-
-
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
Fix types for @types/react@18 #1798
Conversation
Hi guys, any update? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested with the changes and works fine 👍
Hey any updates on when this will get released? |
@leeroyrose You'll have to ask @diegomura and @jeetiss, I don't have commit / publishing access. |
Any update on getting this merged? |
@diegomura @jeetiss I saw that you released a new version But would you do this in a minor instead? |
Hey @diegomura , this seems good, any plan to merge it ? |
Please could you release this update because we are trying to use the SVG component but without the children props in the types we cannot build the project. |
I ended up creating custom components until an official update is released. import ReactPDF from '@react-pdf/renderer';
import { FC, PropsWithChildren } from 'react';
export const Svg: FC<PropsWithChildren<ReactPDF.SVGProps>> = ({ ...props }) => (
<ReactPDF.Svg {...props} />
);
export const G: FC<PropsWithChildren<ReactPDF.GProps>> = ({ ...props }) => (
<ReactPDF.G {...props} />
);
export const ClipPath: FC<PropsWithChildren<ReactPDF.ClipPathProps>> = ({
...props
}) => <ReactPDF.ClipPath {...props} />; |
Thanks very much this has worked for me. |
That really solved, thanks!! |
Any movement on this? |
Hi all, have we got any news on when this will be merged? |
Hi all. Sorry for the lack of response in here. Been very busy and also on vacations 😄 Code looks good, but this would break support for versions prior 18 as far as I can tell. I'm open to suggestions, but I would like to prevent that as much as possible. |
This is really issue with all of my projects and using ts-ignore in someplace to overcome these. Most of project are using recent version of react. Better to support the latest with new react-pdf versions |
@chathu-novade isn't that a bit subjective? Not all projects can afford upgrading react so easily. So bumping react-pdf to 18 without being backwards compatible will break it to many. Merging this will just mean switching the sub-group of users to which this lib will be broken |
I mean we can release with a major version with react 18 support. Like many other react related projects does. I'm open to other suggestions. There are lot of issues created asking for 18 support. |
For this PR I think react types needs to be updated to use this. Which also currently we have done since we had issues with old types with react-pdf/renderer with Typescript. |
Yeah I would also suggest this. Often it's not reasonable to support all old versions of dependencies in a backwards-compatible way. I've seen other major open source libraries also take this approach of only supporting React 18+ in the new versions. |
Thanks for the feedback! @karlhorky can you share what those libs are? I'm curious how they handled that. This project is in the most part very React agnostic (except for the reconciler and types) so dropping support just to have those merged seems a bit overkill. I wonder if there's a way to (via a postinstall script maybe) toggle deps based on the targeted react version |
Can't remember the other ones off the top of my head, but considering how large of a release v18 is, I would imagine there will be more than just one. Another way of going about it (if backwards compatibility is very important to you) is that you could maintain two versions - Maintaining conditional types / scripts seems difficult to deal with / buggy to me, but that would also be an option. |
Thanks @karlhorky ! Both cases I think are still maintaining old versions, at least until a certain window. Backwards compatibility is important, as I know for certain some projects and companies using this lib won't have react migration to easy to do. Maintaining 2 parallel versions is a good approach, but this project does not have the dev power gatsby or next has, that why I was curious how I can prevent that. I'll research about prepare or postinstall scripts. Another alternative would be extracting everything that's React version specific (which is not much) to an internal package, and require users to install a specific version of it depending what react version they are targeting. We can default to latest React version always. This is technically branching versions, but in a smaller codebase |
Oh interesting, that may be nicer / less moving parts than postinstall scripts or similar 👍 I've had some bad times with trying to get postinstall scripts to work reliably... |
Thanks for the merge! I'll give it a try in |
Solved a lot of problems! |
@dimitur2204 thanks, i hope so @karlhorky, try |
Tried out |
Ref: #1062 (comment)
Ref: https://github.com/eps1lon/types-react-codemod#implicit-children
Ref: DefinitelyTyped/DefinitelyTyped#46691
Found some time to take a look at the breakages with
@types/react@18
, and opened a PR to fix the types in the @react-pdf/renderer package: #1798However, this does not fix the other packages in the monorepo. And this may cause breakage for @types/react versions lower than 18.
cc @diegomura @jeetiss
Copying my comment here for visibility: