-
-
Couldn't load subscription status.
- Fork 4
Change the jsx callback type type to any #4
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
Conversation
This change makes the automatic runtime of some frameworks assignable to the runtime `hast-util-to-jsx-runtime` expects.
@remcohaszing this feels a bit like a JSX typing bug in preact? Would this be something to address upstream?
To the question on tooling, I'm for keeping type-coverage, in my opinion it provides useful feedback when reviewing type related PRs.
The Preact types are completely correct. This is an assignability issue caused by the unknown here.
Anything is assignable to any or unknown. any is assignable to anything. unknown is only assignable to any or unknown.
A function that accepts unknown, is assignable to a function that accepts more correctly typed argument, but not the other way around. playground link
type UnknownFn = (arg: unknown) => unknown type StringFn = (arg: string) => unknown declare let unknownFn: UnknownFn declare let stringFn: StringFn // This is a type error unknownFn = stringFn stringFn = unknownFn
The situation for hast-util-to-jsx-runtime is the same. It accepts an object with functions whose argument is unknown, but the implementation has a more strictly typed signature.
To the question on tooling, I'm for keeping
type-coverage, in my opinion it provides useful feedback when reviewing type related PRs.
IMO typescript-eslint is better suited for this. I think supports pretty much all features we use from type-coverage.
But I don’t want to focus on that as part of this PR.
Is this issue about compatibility with Preact? Which frameworks don’t work? That’s quite possible but perhaps they need to be tested, and perhaps we can solve it some other way?
Here’s the Preact types: https://github.com/preactjs/preact/blob/main/jsx-runtime/src/index.d.ts
darthmaim
commented
Feb 27, 2024
@types/react@18.2.59 added types for jsx and jsxs. I think this PR would resolve the following error that now occurs after updating.
Type error: 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>'.
31 |
32 | const tree = starryNight.highlight(code, scope);
> 33 | const reactNode = toJsxRuntime(tree, { Fragment, jsx, jsxs });
| ^
34 |
35 | return reactNode;
36 | };
See also #6.
Closed in favor of #6.
This comment has been minimized.
This comment has been minimized.
React 19 no longer defined `JSX`. It prefers users to use `React.JSX` instead. Without it, it becomes impossible to infer what the types of props for particular components are, what the know tag names are, what the "result" of `jsx()` is. This PR is a patch to prevent errors when `JSX` is not there while still *allowing* `JSX` to exist and for this package to be typed nicely. Related-to GH-4. Closes GH-6.
Initial checklist
Description of changes
This change makes the automatic runtime of some frameworks assignable to the runtime
hast-util-to-jsx-runtimeexpects.For example, see what happens if the type of
typeis toggled in this playgroundtype-coveragefails for this PR. I see 2 possible solutions:JsxandJsxDevdefinitions into a.d.tsfile, so we can add atype-coverage:ignore-next-linecomment.type-coverage. Personally I don’t find it very useful anyway.