-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
I'm trying to use webpack on a UI application which makes use of @graphiql/react
and I see the following error:
ModuleNotFoundError: Module not found: Error: Can't resolve 'react/jsx-runtime' in 'C:\...\node_modules\@graphiql\react\dist'
Did you mean 'jsx-runtime.js'?
BREAKING CHANGE: The request 'react/jsx-runtime' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
On closer inspection I notice that the distributed ES module @graphiql/react/dist/index.mjs
includes the following (slightly obfuscated) line:
import { jsx as o, jsxs as T, Fragment as j } from "react/jsx-runtime";
In React 18's package.json
there is an explicit exports
field which maps the import react/jsx-runtime
directly to react/jsx-runtime.js
, so this works. However, in React 17 or React 16 (which is what we're using), there is no exports
field, which means that (as this is an ES module) an explicit file extension is mandatory. Without it, module importing fails.
Expected Behavior
I would expect a webpack build to work here.
Note that adding an explicit ".js" on the end of that import does fix the problem.
Steps To Reproduce
Add src/index.js
:
import * as GraphiQLReact from '@graphiql/react'
console.log(GraphiQLReact)
Then run:
npm install webpack webpack-cli react@16 react-dom@16 @graphiql/react
npx webpack-cli build
Environment
- GraphiQL Version: 0.19.4
- OS: Windows 11
- Browser: N/A
- Bundler: webpack
react
Version: 16graphql
Version: 16.7.1
Anything else?
A workaround is to set
resolve: {
alias: {
'react/jsx-runtime': 'react/jsx-runtime.js'
}
}
in one's webpack configuration. However, I feel that this should just work out of the box instead of requiring this workaround.