Skip to content
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

Support for Kotlin Nullability in TypeScript Type Generation #3162

Open
SebastianKuehnau opened this issue Jan 16, 2025 · 4 comments
Open

Support for Kotlin Nullability in TypeScript Type Generation #3162

SebastianKuehnau opened this issue Jan 16, 2025 · 4 comments
Labels
enhancement New feature or request hilla Issues related to Hilla

Comments

@SebastianKuehnau
Copy link

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

@SebastianKuehnau SebastianKuehnau added enhancement New feature or request hilla Issues related to Hilla labels Jan 16, 2025
@taefi
Copy link
Contributor

taefi commented Jan 17, 2025

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
Copy link
Contributor

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

@platosha
Copy link
Contributor

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
Copy link
Contributor

platosha commented Jan 21, 2025

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

@Legioth Legioth added this to Roadmap Jan 28, 2025
@github-project-automation github-project-automation bot moved this to Under consideration in Roadmap Jan 28, 2025
@Legioth Legioth moved this from Under consideration to March 2025 (24.7) in Roadmap Jan 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request hilla Issues related to Hilla
Projects
Status: March 2025 (24.7)
Development

No branches or pull requests

3 participants