esm-dev
Failed to import - preact combined with mui
Failing module
I am not entire sure where it fails. here some dummy code
import { Button } from "https://esm.sh/stable/@mui/[email protected]?alias=react:preact/compat,react-dom:preact/compat,react/jsx-runtime:preact/jsx-runtime&[email protected]&target=es2020"
import { render } from "https://esm.sh/stable/[email protected]?target=es2020"
# doing something with it
Error message
After onload I got this:
| n.useContext | @ | react.mjs:2 | |
|---|---|---|---|
| ss | @ | getInitColorSchemeScript.js:20 | |
| ps | @ | getInitColorSchemeScript.js:20 | |
| Q | @ | getInitColorSchemeScript.js:20 | |
| S | @ | experimental_extendTheme.js:125 | |
| (anonymous) | @ | CircularProgress.js:21 | |
| t | @ | index.js:186 | |
| _e | @ | create-context.js:3 | |
| M | @ | create-context.js:3 | |
| z | @ | create-context.js:3 | |
| M | @ | create-context.js:3 | |
| z | @ | create-context.js:3 | |
| ne | @ | create-context.js:3 | |
| M | @ | create-context.js:3 | |
| z | @ | create-context.js:3 | |
| ne | @ | create-context.js:3 | |
| M | @ | create-context.js:3 | |
| z | @ | create-context.js:3 | |
| M | @ | create-context.js:3 | |
| z | @ | create-context.js:3 | |
| M | @ | create-context.js:3 | |
| oe | @ | create-context.js:3 | |
| (anonymous) | @ | index.js:30 |
Additional info
- esm.sh version: stable (other versions are not supported for this dependency injection)
- Browser version: firefox, chrome, brave, tested many
Unfortunately I don't know how to write the minimal working example which fails, but maybe someone already knows where the problem is just by seeing these special imports.
EDIT: I just know that it worked last week but now it fails - so something has changed on esm.sh to the worse.
I guess that despite the same preact version is specified, the two imports use different preact versions under the hood, or one still uses react instead of preact or something like this. Any help is highly appreciated.
seems the server can not handle alias react/jsx-runtime:preact/jsx-runtime correctly, i will looking into it
Mini update: I thought I could workaround this easily, but actually not completely. Hence I still rely on esm.sh and this bug being solved.