Je Xia

The `exports` is totally chaos, i tried to respect the spec but there are a lot of edge cases

i'm not sure, there are too many options now... i will look into the `element-plus` package

seems it's types bug, you can disable the types by `?no-check` query, i will look into it

oh, i will take a look

`import { renderToReadableStream } from "https://esm.sh/[email protected]/server"` just works, https://unpkg.com/browse/[email protected]/package.json check the 43 line, the latest update the server will resolve the export field correctly, `server.browser` doesn't have the types in...

yes, the version problem is painful, especially with react

i plan to get rid of it, the idea is adding a `stable` channel - `esm.sh/react` -> `cdn.esm.sh/stable/[email protected]/esnext/react.js` - `esm.sh/react?unstable` -> `cdn.esm.sh/v78/[email protected]/esnext/react.js` basiclly, we fix the stable channel to a...

when we updated the build version of the `stable` channel, we need to purge the cdn cache, but the client/deno need to reload/clean the cache, that's may a problem

the redirect of https://esm.sh/v78/@types/react-dom@%5E18/X-ZC9yZWFjdEAxOC4xLjA/server~.d.ts is not right, i will fix it

now the server responses `x-typescript-types` with semver versioning, for example, `react@18` will use `https://esm.sh/v80/@types/react@^18/index.d.ts`, then `https://esm.sh/v80/@types/react@^18/index.d.ts` will redirect to `https://esm.sh/v80/[email protected]/index.d.ts`