Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable jsxImportSource #718

Closed
gagoar opened this issue Jan 28, 2021 · 4 comments 路 Fixed by #2349
Closed

Enable jsxImportSource #718

gagoar opened this issue Jan 28, 2021 · 4 comments 路 Fixed by #2349

Comments

@gagoar
Copy link

gagoar commented Jan 28, 2021

馃憢馃徎 @evanw, thanks for your amazing project!

We were moving a group of tooling to use esbuild (from rollout + tsc) and we started having errors given that we use jsxImportSource in our tsconfig.json in order to enable the use of @emotion/react. This has allowed us to avoid adding the pragma on every file.

We got this idea from here

in the meantime, is there a workaround to make it work?

We tried to add --jsx-factory=jsxs but the module is not there.

Thanks.

@evanw
Copy link
Owner

evanw commented Jan 28, 2021

@gagoar
Copy link
Author

gagoar commented Jan 29, 2021

So we tried, but we end up having issues after the compilation

we don't really know what's the module that we should provide to --inject flag. We tried every version under the @emotion/react/jsx-runtime/dist/

esbuild --bundle ./src/browser_action/index.tsx --define:process.env.NODE_ENV=\\\"production\\\" --inject:./node_modules/@emotion/react/jsx-runtime/dist/emotion-react-jsx-runtime.browser.cjs.js --jsx-factory=jsxs --platform=browser --target=chrome86,firefox83 --outdir=dist/browser_action/

The error we get:
Uncaught ReferenceError: jsxs is not defined

this is our tsconfig.json

{
  "compilerOptions": {
    "baseUrl": "./",
    "esModuleInterop": true,
    "importHelpers": true,
    "jsx": "react-jsx",
    "jsxImportSource": "@emotion/react",
    "lib": ["dom", "esnext"],
    "module": "ESNext",
    "moduleResolution": "node",
    "noFallthroughCasesInSwitch": true,
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "resolveJsonModule": true,
    "sourceMap": true,
    "strict": true,
    "target": "es2017"
  },
  "exclude": ["node_modules"],
  "include": ["src", "test", "src/*.json"]
}

Any suggestion you might think that would do the trick?

@evanw
Copy link
Owner

evanw commented Jan 29, 2021

The inject feature is just a way to auto-import a variable in esbuild. It by itself has nothing to do with React. The file to inject has to be in ESM format and will probably be something you end up writing yourself.

When you inject a file with esbuild, all named ESM exports in that file become auto-importable identifiers. Every time one of those named exports is referenced in another file without being declared in that file, an import is automatically generated for that identifier from the injected file.

So if you want to auto-import foo from a file called bar.js everywhere in your project, you could inject a small shim file (which you create) that looks like export {foo} from "./bar.js" to accomplish this. Then you can use foo without having to import bar.js first. This should also apply to auto-importing jsx from the file called @emotion/react.

Note that esbuild only supports the standard JSX transform, not the one that's specific to React 17. So if you're using esbuild to transform JSX syntax to JS you'll get the standard JSX-to-JS transform. I mention this because you have "jsx": "react-jsx" in your TypeScript settings. Presumably the library you're using can be configured to use the standard JSX transform, although I'm not familiar with that library.

@Codex-
Copy link

Codex- commented Apr 22, 2022

Hmmmm having essentially a shim to inject for achieving what would typically be just specifying the jsxImportSource feels finicky, and far from ideal.

There is https://www.npmjs.com/package/esbuild-plugin-jsximportsource which helps, however it would be great to see this supported first hand, would it be something you'd be willing to accept a pull request for, Evan?

Offroaders123 added a commit to Offroaders123/heya-electron that referenced this issue Apr 14, 2024
Helping figure out how to have an Electron project with just a bundler, and not a dev environment. I originally was of that mindset for the longest time, while getting into web development. I've been trying to broaden my scope to where it's alright to use bigger tools for things, I think it's probably because now I know how they work though, so it doesn't feel as uncomfortable to use.

To help discern what comes from what with the modern tooling nowadays though, I thought it would be good to try help exercise this concept again, I can learn from it as well. I think modern tools are much better than they used to be though, so it's less of something to worry about, at least partially. I still don't like all-or-nothing tools either. If they provide an inlet for the configuration that I need to customize though (Vite does do this :) ), then I think it's alright to use it as an abstraction.

https://www.reddit.com/r/electronjs/comments/1c3zwps/electron_react/

Tried to stick with Solid for this demo, but I'm not completely sure how to configure that at the esbuild level to import from the correct module.

Another thing to note with this is that it fully works with plain JS too, I only used TypeScript because that was already part of this stack of mine. I think I can look into making a pure JSDoc typings commit next too, to make it more vanilla-esque too.

https://www.freecodecamp.org/news/bundle-a-basic-react-application-using-esbuild/
https://esbuild.github.io/getting-started/#build-scripts
https://esbuild.github.io/content-types/#using-jsx-without-react
evanw/esbuild#718
https://github.com/amoutonbrady/esbuild-plugin-solid
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants