Closed daniele-orlando closed 1 week ago
Looks like the generated typings are different with as const
.
export declare const Case1_ImageJpegType = "image/jpeg";
versus
export declare const Case2_ImageJpegType: "image/jpeg";
Exactly why, I couldn't say, but I'm guessing the problem is related to the lack of an assigned value in the latter.
Exactly. It is a sneaky difference in the generated .d.ts
file. I don't know the exact semantic difference between the two
export declare const A1 = 'A'
export declare const A2: 'A'
For mere curiosity, aside from the issue explained, I would be glad if someone could point me to a resource/documentation explaining the difference between the two syntaxes.
At the attention of: @ahejlsberg
@RyanCavanaugh
// Widening literal type
export declare const A1 = 'A'
// Nonwidening literal type
export declare const A2: 'A'
See also https://mariusschulz.com/blog/literal-type-widening-in-typescript
The difference is basically that a reference to the unannotated one is preferentially string
but can act as "A"
in context, whereas the other is always just "A"
. This difference needs to exist for idiomatic code like this:
const DefaultUserName = "anonymous";
const users = [DefaultUserName];
// OK
users.push("bob");
vs here with the nonwidening behavior, you get an error:
const DefaultUserName = "anonymous" as const;
const users = [DefaultUserName];
// Error
users.push("bob");
Thanks @RyanCavanaugh for the clarification about the two syntaxes.
What I still find strange is the fact that the widened form export declare const A1 = 'A'
can be used as value for an enum, while the nonwidening form export declare const A2: 'A'
can't be used as enum value.
From what I understand from your explanation and from the article literal-type-widening-in-typescript, it should be the exact opposite or at least a nonwidening form should still be a valid enum value.
I understand the rationale for the difference with respect to how it affects typing now. Is the lack of a literal value in the emit what keeps you from being able to treat it as such? Would it be possible to emit export declare const A2: 'A' = 'A'
or export declare const A2 = 'A' as const
instead, and if so would that solve the problem?
This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.
@RyanCavanaugh please can you reopen the issue? It seams to be an issue with the enum rather than a feature.
Given these two forms
export const Case1_ImageJpegType = 'image/jpeg' // Valid. GOOD.
export const Case2_ImageJpegType = 'image/jpeg' as const // Invalid. BAD
enum MyEnum {
Case1 = Case1_ImageJpegType,
Case2 = Case2_ImageJpegType,
}
they should be both valid enum values. Especially the second one, which at the moment is treated as invalid and shouldn't.
cc: @weswigham @jakebailey
Since this is "working as intended", I think it needs to be approached as a proposal to change the emit.
Would it be possible to emit
export declare const A2: 'A' = 'A'
orexport declare const A2 = 'A' as const
instead, and if so would that solve the problem?
@daniele-orlando can you open a separate issue for that? Thanks
Got it. I'm going to open a proposal issue about it. Thanks for the help.
π Search Terms
enum
π Version & Regression Information
TypeScript: 5.5.3
β― Playground Link
Reproduction Project
π» Code
π Actual behavior
Exporting a string
as const
breaks string enums.π Expected behavior
Exporting a string with or without
as const
should not break string enums.should behave the same when used as