Type error: 'Book' cannot be used as a JSX component.
Answered
Bighead carp posted this in #help-forum
Bighead carpOP
For some reason when I
next build locally, it's fine, but when I deploy on Vercel, I get this errorAnswered by Bighead carp
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
Bighead carpOP
Webstorm doesn't complain about the types
what exactly is the
Book?is it a component/SVG or something else?
Bighead carpOP
It's just a lucide icon
Smells like there are two different types/react versions installed
Bighead carpOP
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
Bighead carpOP
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@Bighead carp 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
Bighead carpOP
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
Bighead carpOP
Right but how would
app/web have access to any react in node_modules from app/docsBighead carpOP
@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
Bighead carpOP
could it be to do with my tsconfig?
No idea, but if it works, it works, doesn’t it
Bighead carpOP
I'm not going to import react into every file
Adding this to my tsconfig fixed it
what a stupid bug.
Bighead carpOP
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
Bighead carpOP
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