Support for Kotlin Nullability in TypeScript Type Generation

[SebastianKuehnau]

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:

data class MyDto(
    val name: String,
    val description: String?
)

The generated TypeScript type looks like this:

export interface MyDto {
  name: string; // Correct
  description: 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

Additional context

Kotlin Version: 2.1.0
Hilla Version: Vaadin 24.6.2

[taefi]

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.

[platosha]

Using kotlin-reflect to extract the nullability flag should work nicely.

[platosha]

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.

[platosha]

Ideally, kotlin-reflect should be optional dependency only required for Kotlin users.

[cromoteca]

RetentionPolicy.CLASS means that those annotations are not available at runtime, when Hilla checks for nullability. We can only support annotation with RetentionPolicy.RUNTIME.