Heads-up: react-konva build break after @types/react 18.3 auto-upgrade
Railway installs grabbed @types/react 18.3 (we declare "^18.0.37"), which dropped implicit children from React.FC/ForwardRefRenderFunction. That breaks react-konva (Stage/Layer/Group no longer accept children) and any Konva configs relying on className/padding/cropX/Y. Dev boxes kept older node_modules so it only surfaced in deploy.
Not sure if this will break anything else, just wanted to notify.
7 Replies
Hi @Zuck. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Thank you for the heads-up regarding the @types/react 18.3 update and its impact on react-konva and related components. Based on the knowledge sources provided, there is no explicit mention of this specific issue with react-konva or the @types/react 18.3 update in the Wasp documentation or issue tracker.
However, the migration guide for Wasp 0.12.x does specify that the recommended @types/react version is "^18.0.37" in the generated package.json, which matches your current declaration. This suggests that Wasp projects are expected to use a compatible @types/react version, but it does not address the breaking change introduced in 18.3 or provide guidance on pinning or downgrading type dependencies to avoid such issues. The sources also discuss challenges with dependency versioning and the need for tighter control or user overrides, but do not offer a built-in solution for this scenario yet Migrating Your Project to the New Structure, Consider allowing users to specify some NPM dependency versions themselves.
In summary, while Wasp currently expects you to manage your own dependencies in package.json, there is no official guidance or tooling in Wasp to handle this specific @types/react upgrade issue. You may need to manually pin @types/react to a version before 18.3 in your package.json as a workaround until a more robust solution is available.
If you need tighter control over dependency versions or want to avoid such surprises in the future, this is a known area of improvement for Wasp, as discussed in the issues about dependency management and pinning Should we pin our NPM dependency versions down even tighter?.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Zuck, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
@kapa.ai but i cant pin it because wasp requires
Wasp requires package "@types/react" to be version "^18.0.37" in package.json.
Let me check the knowledge base for you again. One moment! :books:
----------------------
You're correct—Wasp currently enforces that certain dependencies, like @types/react, must match the exact version it specifies (e.g., "^18.0.37"). If you try to pin @types/react to a lower version or a specific patch version to avoid breaking changes (such as those introduced in 18.3), Wasp will refuse to build and report a version conflict. This is a known limitation in the current version of Wasp: you cannot override or pin versions of dependencies that Wasp manages internally, even if a breaking change in a minor or patch release causes issues in your project.
The Wasp documentation and issue tracker confirm this behavior:
In the current version of Wasp, if Wasp is already internally using a certain dependency (e.g. React) with a certain version specified, you are not allowed to define that same npm dependency yourself while specifying a different version. If you do that, you will get an error message telling you which exact version you have to use for that dependency.There are ongoing discussions and plans to improve this, such as allowing users to specify their own versions (possibly via npm aliases), but this is not yet implemented. For now, you are limited to the versions dictated by Wasp, and there is no built-in workaround for pinning @types/react to avoid the 18.3+ breaking change. The only option is to wait for Wasp to update its dependency management or provide more flexibility in future releases Allow specifying npm dependency that Wasp already uses, with different version. If this limitation is blocking your deployment, you may want to follow or contribute to the related issues on GitHub to help prioritize this feature. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Zuck, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
This means Wasp dictates exact versions of certain packages, so for example you can't choose the version of React you want to use.
Project Dependencies
@Wasp Team ya in shambles here trying a whole bunch of
workarounds
The trigger
Package.json lists @types/react as "^18.0.37". That caret means npm is free to install any newer 18.x release.
A few days ago DefinitelyTyped shipped @types/react 18.3. They made a backwards-incompatible change: React.FunctionComponent, ForwardRefExoticComponent, etc., no longer auto-add children to props. That’s intended for apps that opt into the “use explicit children” pattern.
Because the version range is open, fresh installs (Railway deploys, wasp clean && npm install) now pull 18.3.3 instead of the older 18.2.x your local node_modules still had.
Why that breaks Konva
react-konva’s type stubs haven’t been updated for the new behaviour. They still model Stage, Layer, Group, etc. as React.FC components that expect a children prop and let you pass arbitrary Konva config fields like className, strokeOpacity, onContentMouseDown, etc.
Once children disappears from React.FC, the generated prop types lose it, so every <Stage>{...}</Stage> or <Group> starts erroring (“Property 'children' does not exist…”). The same thing happens for config props that aren’t explicitly declared in Konva’s own .d.ts files (className, strokeOpacity, etc.), because TypeScript becomes stricter as soon as the wrappers no longer mask the missing fields.
@Zuck Okay got it! We're on the company retreat this week, so we might be a bit slow to respond, but I'm looking at it now
Okay, so there are a number of issues here. On our side, we need to give you a way to have stricter dependency ranges, and to have a more effective package lock for outputted code. Both of these are coming (1), (2).
This is a bigger effort so I don't think we're able to push it out in a timely way for you.
Let me suggest a workaround then:
1.
npm i @types/react@~18.2 @types/react-dom@~18.2
2. Edit the package.json to add the ranges that wasp needs
3. The old resolved version will still stay in your package-lock.json
4. Now if you run wasp build, it will use those dependencies you declared in your own project
Can you try it out and see if it works?@Carlos sorry im on EST just woke up!
were launching in private beta today so bad time for this to happen hahaha
okay testing workoaround now
@Carlos this isnt working im getting errors in the wasp build step
i think im able to augment a lot of the types but the WASP SDK needs to be fixed as well i think
@Wasp Team i've gotten wasp start working again with patch-package but still strugglign with wasp build start
added a diabolical patch to my docker file and everything is working now
but do not want to have to keep this patch
hey! sorry we just got back from the retreat; let me check with the team what we should do, because it seems we might have to push out a hotfix today and a version pinning for this might fit in
can you share the dockerfile workaround? also what kind of types in the Wasp SDK need fixing?