You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When generating TypeScript types from Kotlin backend models, nullability information is not always preserved. For example, a nullable Kotlin field (String?) is often mapped to a string type in TypeScript instead of string | null. This causes issues where TypeScript developers assume the field is non-nullable, leading to potential runtime errors.
Given the following Kotlin data class:
data classMyDto(
valname:String,
valdescription:String?
)
The generated TypeScript type looks like this:
exportinterfaceMyDto{name: string;// Correctdescription: string;// Incorrect! Should be string | null}
Describe the solution you'd like
Update the TypeScript type generation logic in Hilla to correctly map Kotlin nullable types (T?) to TypeScript T | null.
Describe alternatives you've considered
Maybe JSR305 could be used to annotate the affected source code explicitly
I have the same problem, but the other way around, which means I always get optional types e.g. string? in the generated TS interface. I only can reproduce your issue, if I have a package-info.java in the same package that annotates the whole package with @NonNullApi. In that case, everything would be non-null in TS.
P.S: The use of optional types T? in the generated TS interfaces instead of T | undefined is intentionally preferred in Hilla generator (where possible), to prevent forcing the developers from writing boilerplate codes just to initialize some property value to undefined.
Let's assume that the language overrides any other annotations, including JSR305 @Nullable and Spring's @NonNullApi. So in Kotlin context, only Kotlin language nullablility should apply.
Describe your motivation
When generating TypeScript types from Kotlin backend models, nullability information is not always preserved. For example, a nullable Kotlin field (String?) is often mapped to a string type in TypeScript instead of string | null. This causes issues where TypeScript developers assume the field is non-nullable, leading to potential runtime errors.
Given the following Kotlin data class:
The generated TypeScript type looks like this:
Describe the solution you'd like
Update the TypeScript type generation logic in Hilla to correctly map Kotlin nullable types (T?) to TypeScript T | null.
Describe alternatives you've considered
Maybe JSR305 could be used to annotate the affected source code explicitly
Additional context
Kotlin Version: 2.1.0
Hilla Version: Vaadin 24.6.2
The text was updated successfully, but these errors were encountered: