-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
TypeScript errors after installing 7.2.3 relating to @types/react-redux now being a "dependency" #1700
Comments
Hmm. That's a good point. I just grabbed the latest I'm not clear on how I'm unfortunately busy with my day job atm. Can you do me a favor and put together a couple examples of how things behave with 7.2.3 and differing versions of React and the types? |
Should the |
The intent of the change was to force that If this turns out to have been a really bad idea we can definitely backtrack, but I'd like to get more info on exactly what scenarios are busted here. |
@markerikson From what I can see, the latest 16.x and 17.x of the @types/react and @types/react-redux are compatible (i.e no TS errors) and similarly, react 16 and and 7.2.3 react-redux are ok too (besides the TS errors). Our main blocker for upgrading to react 17 is enzyme not being compatible, so for now, we've gone back to 7.2.2. |
we are in the same situation as @marchaos. i was also surprised to find the types inclusion in a minor version bump, given that it causes TS errors and has the potential to break build processes |
Two quick thoughts:
So far no one has provided additional information indicating what a specific problem might be with regards to types versions compatibility, and my focus has been finalizing our RTK Query package and merging it into Redux Toolkit. So, no, it hasn't been on my radar. If this is still an active problem for people, I need more info about what sorts of actual interactions cause these errors - combinations of package versions, etc. |
I'd like to add that |
Hmm. Hadn't thought about that part, but we did at least eliminate the use of Redux as a runtime dependency. |
mmm, but did you really? :-) The entry Lines 49 to 56 in 86e962e
Similarly for the @types/react-redux types (probably right in this case): (To be clear, I don't think this is a huge problem, after all |
redux changed their minor version and now @types/react-redux installs redux@4.0.0 and my code installs redux@4.1.0. What do you think about including d.ts files in this repo instead? (I don't plan to describe what do I think about DefinitelyTyped monorepo because it definitely violates Code of Conduct). I can create a PR with these changes |
This is true, but on my project, this results in installing redux 4.1 for both, as redux 4.1 fulfills That said I think your proposal makes sense, especially if the maintainers of the project also maintain these types. |
Thing is, we don't maintain the React-Redux types ourselves. The community has always done so. That's why they lived in DefinitelyTyped instead of in this repo. We did add myself and Lenz to the "list of maintainers for these types" in DTS recently because someone else had filed a PR that marked one of the types as When we get around to working on React-Redux v8, we'll rewrite the library in TS. Until then, the types can stay where they are. |
Given that React-Redux v8 will be out shortly, and is written directly in TS, I think this can be closed as OBE. |
After installing 7.2.3, our build failed due to TS error pertaining to duplicate declarations. (see below). We've seen this before and I tracked it down to the release of react-redux last night. We initially had
@types/react-redux
in our package.json, which has since been removed, but the errors were still present. Due of the sub dependency of@types/react
being 17.0.3 in react-redux,and our explicit
@types/react
being16.14.5
,@types/react
is not deduped. If we upgrade to17.0.3
as well, then we no longer get errors, but this is forcing us to have a miss-match between our react version and the@types/react
version.It's questionable as to whether 7.2.3 supports react 16 because of this. Maybe this is a known issue and the action described above is what you'd expect?
TS Errors for reference for others:
The text was updated successfully, but these errors were encountered: