Type error: 'Book' cannot be used as a JSX component.
Answered
Southern rough shrimp posted this in #help-forum
Southern rough shrimpOP
For some reason when I
next build locally, it's fine, but when I deploy on Vercel, I get this errorAnswered by Southern rough shrimp
Nvm, that just pushed the error to 'next' package. What solved it is by changing
shared-workspace-lockfile = trueto shared-workspace-lockfile = falsein my .npmrc32 Replies
Southern rough shrimpOP
Webstorm doesn't complain about the types
what exactly is the
Book?is it a component/SVG or something else?
Southern rough shrimpOP
It's just a lucide icon
Smells like there are two different types/react versions installed
Southern rough shrimpOP
I did move to a monorepo recently
The root package.json has no dependencies, and my
app/web/package.json has react 19 installedeven simple stuff like this isnt working
i cant even use
next/link??my guess is that you have something like
when i have a monorepo i have a few rules on dep versions:
* only a single version of any given package is used across all
* versions are always pinned, so not
maybe check your
"@types/react": "^19.0.0" in more than one place and somehow it's installed as two different versions in different placeswhen i have a monorepo i have a few rules on dep versions:
* only a single version of any given package is used across all
package.json's* versions are always pinned, so not
^19.0.0 but, say, 19.0.3maybe check your
package.json and follow those two rules, then wipe lock file, node_modules and reinstall everything and see if it helps@joulev my guess is that you have something like `"@types/react": "^19.0.0"` in more than one place and somehow it's installed as two different versions in different places
when i have a monorepo i have a few rules on dep versions:
* only a single version of any given package is used across all `package.json`'s
* versions are always pinned, so not `^19.0.0` but, say, `19.0.3`
maybe check your `package.json` and follow those two rules, then wipe lock file, `node_modules` and reinstall everything and see if it helps
Southern rough shrimpOP
Theyre in separate apps (as part of a turborepo)
And the issue is happening on
apps\web, which is pinned to 19.0.0I think this whole monorepo is fucked
I just get random errors like this when running
pnpm install, even though this branch hasnt even touched the docs app@Southern rough shrimp Theyre in separate apps (as part of a turborepo)
bingo, well not a perfect bingo but my guess of a react package having separate versions is correct
you have to figure out a way to use the same version number across packages here. monorepos in my experience are not very friendly towards the same package being installed twice in different versions – that said, try other package managers to see if their implementations of monorepo work
you have to figure out a way to use the same version number across packages here. monorepos in my experience are not very friendly towards the same package being installed twice in different versions – that said, try other package managers to see if their implementations of monorepo work
Southern rough shrimpOP
I really do hope that isnt the case. If you're right then turborepo is pretty useless
I've seen people wiith 200+ projects in a turborepo and the chances of them all using the same version of react is very low
actually not turborepo's fault, turborepo is just a task runner. it's more so the package manager's fault
Southern rough shrimpOP
Right but how would
app/web have access to any react in node_modules from app/docsSouthern rough shrimpOP
@joulev do you have any idea
If I go around all my files and import React it fixes it
No idea
When version mismatches happen, sometimes it just magically works - this is my only explanation for whatever could be happening here
Southern rough shrimpOP
could it be to do with my tsconfig?
No idea, but if it works, it works, doesn’t it
Southern rough shrimpOP
I'm not going to import react into every file
Adding this to my tsconfig fixed it
what a stupid bug.
Southern rough shrimpOP
Nvm, that just pushed the error to 'next' package. What solved it is by changing
shared-workspace-lockfile = trueto shared-workspace-lockfile = falsein my .npmrcAnswer
Southern rough shrimpOP
I guess you were right, since they all shared a lockfile for some reason it was crossing the dependencies
yeah this kind of thing is why i have the two rules above, i learned them the hard way