Uncaught ReferenceError: React is not defined
Hey there! Please help. I can't figure out this error.
I have a tiny solid-js project that works ok. I wanted to reuse some code and created this npm package(https://www.npmjs.com/package/@illlia/solid-css-styled?activeTab=code) (1 file basically). In essence I replace my inside project code with a 1:1 replica from that npm package.
All npm package does is creates "tailwind-styled" utility that works like solid-styled-components, but uses tailwind classes. Anyway, that function returns <Dynamic ... > solid-js component.
When i try to use code from that npm package in my solid-js project I get
error
I can't figure out why. I have tests in my npm package that pass successfully that are using solid-testing-library. I don't have any dependencies on React in any of my projects
The only dependency i have inside my npm package is solid
npm
@illlia/solid-css-styled
css styled utility for css utility frameworks like tailwind. Latest version: 0.0.3, last published: 13 minutes ago. Start using @illlia/solid-css-styled in your project by running
npm i @illlia/solid-css-styled
. There are no other projects in the npm registry using @illlia/solid-css-styled.8 Replies
Here's my tsconfig in npm package
tsconfig inside my project
and standard vite.config.js
if i copy the code from npm package inside my project, it works. Also tests inside my npm package pass both imported from ./src and from the built version (imported from ./dist)
interestingly enough, "pnpm build && pnpm serve" works and the project is served correctly, while only "pnpm dev" has the error i described
when i inspect dev tools error i see this . I don't know why that specific JSX code is using React.createElement
here's the same code inside the ./dist folder. It seems that for some reason vite tries to use React to transform JSX from that specific part
I tested ur library out and was able to reproduce that error. I always use https://github.com/solidjs-community/solid-lib-starter this starter when I want to build a lib. It builds to a bunch of formats and updates your package.json accordingly.
All jsx-tooling defaults to react, so that
React not found
error is pretty typical. I have no idea why you are getting that error.@bigmistqke thanks for looking into it. I saw other solidjs libraries that use tsc to compile code and i didn't find any major differences between configs, so yeah, it's kind of weird. I'll try your suggestion
@bigmistqke I have figured it out. My "index.ts" file was exporting everything from "css-styled.tsx" file. On practice with internal files it works fine. Apparently, it doesn't work for libs and JSX defaults to React. I suspect it's some sort of a bug. After renaming "index.ts" to "index.tsx", it works fine 🔥 🙄
Mm strange bc that's a very common pattern w libraries.
aa
it might be https://vitejs.dev/guide/build#library-mode
what do you mean? I'm not using vite for library build. I'm using tsc.
I don't think it's a library issue. I'm guessing it's either vite or more likely vite solid plug-in bug. Because app production build works fine.
I choose to blame
tsc
(or perhaps esbuild)
This only affects output of JS files that started in .tsx
files.
While JSX seems to work in .ts
files, it assumes the transform for React.
The configured transform only seems to kick in for .tsx
files.
I could be wrong but TS has a mountain of issues.TSConfig Reference - Docs on every TSConfig option
From allowJs to useDefineForClassFields the TSConfig reference includes information about all of the active compiler flags setting up a TypeScript project.
@peerreynders but if that was the case, why does production build using the same library work fine?
tsc correctly bundles jsx and exports it through index.js file. It's the actual project build (in development) that assumes react (using vite)
That's a fair statement which is why esbuild could be the culprit as it's only used in dev.
I've just observed it too often that the LSP would get confused for no good reason screaming for React, requiring an LSP reboot; TS (configuration) complexity has gotten to a point where you have to know your edge cases (e.g. don't use JSX in .ts files) so you don't find yourself wasting time fighting heisenbugs rooted in assumptions that aren't communicated well.