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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(jsx): base for supporting more runtimes #236

Merged
merged 10 commits into from
Feb 7, 2025

Conversation

muningis
Copy link
Contributor

@muningis muningis commented Dec 18, 2024

What:
Support JSX runtimes other than react.

Why:
Allow this to be used with other JSX runtimes supported by mdxjs (https://mdxjs.com/docs/getting-started/#jsx) but not limited to. For example, this can work quite fine with https://hono.dev/ too, eventhough it's not mentioned here (thanks to a fact, that Hono is compatible with React's API)

How:
Adjust bundleMDX to accept jsxConfig (which fallbacks to react).
getMDXComponent will have to be adjusted too, still looking for an approach which would have least breaking changes. Second paramter globals could be used for that, as such:

const { code } = bundleMDX({
  jsxConfig: {
    JsxLib: {
      varName: 'HonoJSX',
      package: 'hono/jsx',
    },
    JsxDom: {
      varName: 'HonoDOM',
      package: 'hono/jsx/dom',
    },
    jsxRuntime: {
      varName: '_jsx_runtime',
      package: 'hono/jsx/jsx-runtime',
    },
  }
});

// ...

import * as HonoJSX from "hono/jsx";
import * as HonoDOM from "hono/jsx/dom";
import * as _jsx_runtime from "hono/jsx/jsx-runtime";
const Component = getMDXComponent(code, { HonoJSX, HonoDOM, _jsx_runtime });

Checklist:

  • Documentation
  • Tests - TODO
  • Ready to be merged

Todo:

  • Readme update
  • Preact tests
  • Hono tests (react compatible, not officially supported by mdx-js)
  • Vue tests
  • Solid tests
  • Svelte tests

@muningis muningis force-pushed the support_more_runtimes branch from cb27722 to b301a41 Compare December 18, 2024 14:55
kentcdodds
kentcdodds previously approved these changes Dec 18, 2024
Copy link
Owner

@kentcdodds kentcdodds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I think I want to lowercase a few things. Other than that, this is perfect :)

kentcdodds
kentcdodds previously approved these changes Dec 18, 2024
Copy link
Owner

@kentcdodds kentcdodds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! One last thing. Could you add a note about this in the readme?

@muningis
Copy link
Contributor Author

Of course! Still have to do few things though:

  • add some unit tests for various runtimes (primarly Vue, Solid, Svelte).
  • modify getMDXBudler - will adjust /client import to fallback/default to React, and /client/jsx will allow passing own JSX bindings+runtime.

kentcdodds
kentcdodds previously approved these changes Dec 23, 2024
Copy link
Owner

@kentcdodds kentcdodds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@muningis
Copy link
Contributor Author

muningis commented Feb 6, 2025

Had quite a busy January, getting back to this! At the moment only solid test's are failing, as it complains about Client Side API usage in Server. Not entirely familiar with Solid that much, will probably jump on their Discord.

WDYT about skipping Solid for now?

@muningis
Copy link
Contributor Author

muningis commented Feb 6, 2025

From Solid’s discord:

I think you'll want to use the latest vite-plugin-solid

this is basically because they gotta compile solid’s code. So mdx-bundler can’t really work just by replacing jsx’s runtimes imports 😞

@kentcdodds
Copy link
Owner

Bummer :(

@muningis muningis changed the title draft: feat(jsx): base for supporting more runtimes feat(jsx): base for supporting more runtimes Feb 7, 2025
kentcdodds
kentcdodds previously approved these changes Feb 7, 2025
Copy link
Owner

@kentcdodds kentcdodds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks almost perfect. I just want to make sure I understand what's going on in the package.json, and I want to ensure that there are no breaking changes for existing users.

Comment on lines 4 to 5
"react": "./react.js",
"jsx": "./jsx.js",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are these? This looks like it actually should be in a export config.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, I don't know what was there... Fixed it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As for breaking changes regression check, probably result.code snapshot test would be best shot.

Create snapshots with separate MR, merge them into main, and then rebase into this.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was mostly just thinking about the imports that people have already. I'm pretty sure that you have everything wired up properly, but I just wanted to double check.

Copy link
Owner

@kentcdodds kentcdodds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@kentcdodds kentcdodds merged commit 70cb04f into kentcdodds:main Feb 7, 2025
3 checks passed
Copy link

github-actions bot commented Feb 7, 2025

🎉 This PR is included in version 10.1.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@muningis
Copy link
Contributor Author

muningis commented Feb 8, 2025

Few typescipt issues found for non-react uses of this. For some reason, I thought it would be good idea to test it on non-typescript repo (and I’m typescript-first guy).

Got fix for type export declarations in package.json, will take a bit for JSX not to enforce react rather use what’s in consumer repo.

Edit: issue is also caused in "inproper" monorepos, where @types/react might be installed and it causes conflicts with JSX from other JSX libs. Not much of an issue then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants