Typescript fail to parse JSX syntax correctly

[GuichiZhao]

import { FC } from 'react';
type Test<X extends string> = X;
const a: Test<'a'> = {} as Test<'a' | 'b'>;
console.log(a);

type TestFn<X extends string> = (args: X) => void;
const b: TestFn<'a'> = {} as TestFn<'a' | 'b'>;
console.log(b);

type TestFC<X extends string> = FC<{ data: X }>;
const c: TestFC<'a'> = {} as TestFC<'a' | 'b'>;
console.log(c);

const a introduce a type error, which is a desired behaviour because 'a'|'b' is not a subtype of 'a', however, if the type parameter is present in place of the function parameter, there is no error because the parameter is contravariant instead of covariant, TS is smart enough to identify the pattern even in place of generic

However, TS is not smart enough to handle const c: TestFC<'a'> = {} as TestFC<'a' | 'b'>; correctly, it reports a undesired error Type '"a" | "b"' is not assignable to type '"a"'. the root case should be TS fail to notice {data:X} present in function paramter

[MartinJohns]

Your search terms seem very excessive. It's better to search for a few related keywords than a full blown description.

[GuichiZhao]

Your search terms seem very excessive. It's better to search for a few related keywords than a full blown description.

I created the issue from the template. I understand that the template is a way to make the issue easier to understand, but my issue is easy to understand already and not related to the template, so I just remove the template

[MartinJohns]

I understand that the template is a way to make the issue easier to understand

The template is meant to allow the team a quick overview of the issue, and filling it out properly is (IMO) a sign of respect as they ask nicely "Please fill in each section completely."

---

I don't see anything wrong with the code you posted or the behavior, it's working as intended. I don't see why you have b in the code example and don't mention it anywhere else (is the behavior for b as you expect or not?), and I don't see what the code has to do the slightest with JSX parsing (you don't make use of JSX anywhere).

This is your code simplified to the relevant bits:

const example: (arg: 'a') => void = {} as (arg: 'a' | 'b') => void;

And this is perfectly valid. The actual function can accept a wider range of types than the function type requires.

There is a certain unsoundness that the implementing function can assign values outside of the target types range (in case of objects), but that's an intentional one / design limitation.

[jcalz]

Please fill out the template properly, every bug report is “related to” it, no matter how easy you think it is to understand. Right now we’re talking about the template and not your issue. If you don’t want that to continue, the best way is to fix it.

Wearing a shirt and shoes isn’t “related to” buying groceries but the local market will still send me away if I’m not doing it.

---

EDIT: I agree with previous comment, this doesn't seem to be a TS bug, and the title seems to be completely unrelated to the code. This really really is not "easy to understand" so if you think there's a problem, please edit to use the template properly and be very careful and clear in your writing.

[GuichiZhao]

I understand that the template is a way to make the issue easier to understand

The template is meant to allow the team a quick overview of the issue, and filling it out properly is (IMO) a sign of respect as they ask nicely "Please fill in each section completely."

I don't see anything wrong with the code you posted or the behavior, it's working as intended. I don't see why you have b in the code example and don't mention it anywhere else (is the behavior for b as you expect or not?), and I don't see what the code has to do the slightest with JSX parsing (you don't make use of JSX anywhere).

This is your code simplified to the relevant bits:

const example: (arg: 'a') => void = {} as (arg: 'a' | 'b') => void;
And this is perfectly valid. The actual function can accept a wider range of types than the function type requires.

There is a certain unsoundness that the implementing function can assign values outside of the target types range (in case of objects), but that's an intentional one / design limitation.

if const example: (arg: 'a') => void = {} as (arg: 'a' | 'b') => void; is perfect valid
Why

type TestFC<X extends string> = FC<{ data: X }>;
const c: TestFC<'a'> = {} as TestFC<'a' | 'b'>;

report an ERROR?

if you put FC<T>=(arg:T)=>void They are exactly the same thing, If you know anything about React, it is very clear that the real implementation of FC does the same thing as (arg:T)=>void especially in terms of how the argument beheive, so there is no point

type TestFC<X extends string> = FC<{ data: X }>;
const c: TestFC<'a'> = {} as TestFC<'a' | 'b'>;

report an error

[GuichiZhao]

Please fill out the template properly, every bug report is “related to” it, no matter how easy you think it is to understand. Right now we’re talking about the template and not your issue. If you don’t want that to continue, the best way is to fix it.

Wearing a shirt and shoes isn’t “related to” buying groceries but the local market will still send me away if I’m not doing it.

EDIT: I agree with previous comment, this doesn't seem to be a TS bug, and the title seems to be completely unrelated to the code. This really really is not "easy to understand" so if you think there's a problem, please edit to use the template properly and be very careful and clear in your writing.

you can see my previous comment

type TestFC<X extends string> = FC<{ data: X }>;
const c: TestFC<'a'> = {} as TestFC<'a' | 'b'>;

should not report an error anyway, do you agree with the point in the first place? But it DOES report an error by the TS engine, So something must be wrong, either TS engine or the implementation of FC from the React TS team/community. But the FC works fine in all other places except the corner case I mentioned above, so I would rather believe it is a TS bug, possibly related to parsing JSX.

[jcalz]

I don’t see a bug in TS and you haven’t complied with my request so I’m not sure there’s much point in continuing. I’ll disengage, good luck.

[GuichiZhao]

I don’t see a bug in TS and you haven’t complied with my request so I’m not sure there’s much point in continuing. I’ll disengage, good luck.

type TestFC<X extends string> = FC<{ data: X }>;
const c: TestFC<'a'> = {} as TestFC<'a' | 'b'>;

There should not be a type ERROR, but TS Engine does report an error; is that obvious enough?
No context, no template, just two lines of deadly simple TS code reveal the problem.

Maybe that is not a TS bug, but at least a React bug. If a large JS community like React can not use TS properly, I believe there are some points worth looking into

[guillaumebrunerie]

There is no error: https://www.typescriptlang.org/play/?ts=5.8.3#code/C4TwDgpgBAYgwgHgCoD4oF4oAowCcD2YAzgFxRICUGaAbvgJYAmA3AFCiTkRHDwIAaUCAA9gEAHaMiUHrnriA5mkx8A3lEYBDYJrKCAvijYBjfOJ5RjZJN16IA5JvvKoq-VE3SbPPo-tQAHyh7ACNnNiA

[GuichiZhao]

There is no error: https://www.typescriptlang.org/play/?ts=5.8.3#code/C4TwDgpgBAYgwgHgCoD4oF4oAowCcD2YAzgFxRICUGaAbvgJYAmA3AFCiTkRHDwIAaUCAA9gEAHaMiUHrnriA5mkx8A3lEYBDYJrKCAvijYBjfOJ5RjZJN16IA5JvvKoq-VE3SbPPo-tQAHyh7ACNnNiA

Replace FC with the real React implementation of FC
It does DefinitelyTyped/DefinitelyTyped#72820 (reply in thread)

The root cause can be the wrong implementation of React rather than TS

[RyanCavanaugh]

@GuichiZhao everyone thinks the template is something they can skip because their bug is so obvious, but we really do need information that's listed there in order to process your report. That's why it's there