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

Type Error on jsx type with react jsx runtime #2463

Open
4 tasks done
mghahari opened this issue Apr 5, 2024 · 5 comments · May be fixed by #2465
Open
4 tasks done

Type Error on jsx type with react jsx runtime #2463

mghahari opened this issue Apr 5, 2024 · 5 comments · May be fixed by #2465

Comments

@mghahari
Copy link

mghahari commented Apr 5, 2024

Initial checklist

Affected packages and versions

3.0.1

Link to runnable example

https://stackblitz.com/edit/vitejs-vite-ahedk8?file=src%2Fmain.tsx

Steps to reproduce

You can see type error in the sandbox for options parameter of the evaluate function. (in main.tsx file)

Expected behavior

Doesn't have type error with evaluate function when we run the sample code from documentation:

import {evaluate} from '@mdx-js/mdx'
import * as runtime from 'react/jsx-runtime'

console.log(await evaluate(file, runtime))

Actual behavior

Type error:

Argument of type 'typeof import("stackblitz:/node_modules/@types/react/ts5.0/jsx-runtime")' is not assignable to parameter of type 'Readonly<EvaluateOptions>'.
  Types of property 'jsx' are incompatible.
    Type '(type: ElementType<any, keyof IntrinsicElements>, props: unknown, key?: Key | undefined) => ReactElement<any, string | JSXElementConstructor<any>>' is not assignable to type 'Jsx'.
      Types of parameters 'type' and 'type' are incompatible.
        Type 'unknown' is not assignable to type 'ElementType<any, keyof IntrinsicElements>'.

Runtime

No response

Package manager

No response

OS

No response

Build and bundle tools

No response

@wooorm
Copy link
Member

wooorm commented Apr 5, 2024

Heya! Yeah, react did not have types. So there was an error already because types were missing.
Now it has weird new types, and there’s still an error.
You can add a // @ts-expect-error like before. Or, PRs wanted, to improve the types of jsx and such!

@mghahari
Copy link
Author

mghahari commented Apr 5, 2024

Thanks for your response @wooorm. According to your response, the main problem is in the type definitions of the react library.
I reviewed the type definitions for jsx in the DefinitelyTyped repository:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/f1da3cee5648005e07550ae729d4aadee764da3b/types/react/jsx-runtime.d.ts#L22

It seems that it has reasonable types. But it's specific to react.
For mdx-js/mdx, after a non-straightforward journey, I found this for type definition:
https://github.com/syntax-tree/hast-util-to-jsx-runtime/blob/05c087bef85f6dd6a1f1a09abc0aef89236f7f69/lib/index.js#L93

It doesn't have a specific definition for the type property. It's maybe reasonable because it's framework agnostic.

I think any PR for react types will not be accepted because it has reasonable type in its' context.
And we cannot make a PR for hast-util-to-jsx-runtime because it should be framework agnostic.

Do you have any idea for solving this problem?

remcohaszing added a commit that referenced this issue Apr 5, 2024
`@types/react` now has types for `react/jsx-runtime` and
`react/jsx-dev-runtime`. These types are not compatible with the types
provided by `hast-util-to-jsx-runtime`, which are used by MDX.

To resolve the issue, all runtime related options have been changed to
`unknown`. Since the user is supposed to pass in whatever JSX runtime
they imported, this should be sufficient.

This fixes several type errors. An outdated workaround has been removed
from the documentation.

Closes #2463
@remcohaszing remcohaszing linked a pull request Apr 5, 2024 that will close this issue
5 tasks
@wooorm
Copy link
Member

wooorm commented Apr 5, 2024

And we cannot make a PR for hast-util-to-jsx-runtime because it should be framework agnostic.

There might be something doable there? Or, Remco’s PR mentioned above. Though I wonder if there can be some types between no types vs broken types. #2465 (comment)

@mghahari
Copy link
Author

mghahari commented Apr 5, 2024

@remcohaszing, @wooorm
Thank you for investigating on this issue. I don't have enough information about this library for suggesting a feasible solution.
In general, I think we should define a minimal interface that any compatible type can satisfies it.
In this case we don't force a complete and opinionated type and just what's enough to this library works correctly.
But I don't know it's possible to do that in jsDoc format.

@wooorm
Copy link
Member

wooorm commented Apr 5, 2024

Yup! (and: almost everything is possible with jsdoc as in plain ts! and if it isn‘t, we can use plain d.ts files!)

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

Successfully merging a pull request may close this issue.

2 participants