Feat/support gleam lang

[ocapmycap]

What changed

quicktype can now generate ✨Gleam! Given JSON samples or a JSON Schema, it emits custom types, encoders built on gleam/json, and decoders built on gleam/dynamic/decode that round-trip the input. Use --lang gleam from the CLI or gleam from the library.

Why

Gleam has to_json and decode generators for types written in Gleam, but it cannot generate types based on valid JSON or JSON Schema.
Gleam is also the first quicktype target whose Int and Float are disjoint at runtime.
Per existing convention, quicktype will collapse heterogenous JSON numbers to the least precise version in the language. As an example, quicktype takes thise JSON:

[{"bar":123},{"bar":12.3}]

And converts it into, for instance, this Rust:

pub type Foo = Vec<FooElement>;

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct FooElement {
    pub bar: f64, // numbers collapse into f64
}

Widening a whole number to a float is a wrong answer for Gleam, not a cosmetic one, and that shaped the one core change in this PR.
When running the Gleam generator against that same JSON, we are able to produce this:

/// Note this **is** Gleam code, Rust syntax highlighting is the closest thing we have
pub type FooElement {
  FooElement(bar: Bar)
}

pub type Bar {
  BarDouble(Float)
  BarInteger(Int)
}

pub type Foo =
  List(FooElement)

How it works

Two decisions a reviewer might not udnerstand from just the diff:

Recursion. A decoder that reaches itself has to open with decode.recursive, or the generated module compiles clean and then hangs forever when the decoder is constructed. The guard re-runs the decoder body on every decode, so we emit it only where a cycle is broken:

• on the classes and unions that `canBreakCycles picks
• on the JSON value decoder, which is always self-recursive.

Numbers. A new TargetLanguage hook, infersUnionsWithBothNumberTypes, lets a language ask inference to keep [1, 1.5] as Int | Float instead of collapsing it to Float. It is off for every existing language, so their output does not change. Gleam turns it on, and a new priority sample, int-float-union.json, covers the case.

What to check

• The inference hook, since it touches Run.ts, Inference.ts, and Inputs.ts on the path every language takes. Run npm run test:unit locally and confirm in CI that no non-Gleam fixture produces different output.

Risk

Gleam has two runtimes, Erlang and JavaScript, and each treats Int and Float differently. The types generated by this addition do not behave the same at runtime, but a round trip result will always match its source.

Examples

Gist

AI Disclosure

Paired on this with Claude Opus 4.8, 5, and Fable 5.1.

[lpil]

Hello! I'm the creator and lead maintainer of Gleam. Really cool to see this pull request, I've long thought it would be great to have Gleam support in Quicktype.

I've left one note inline about the code that generated which I think is important to resolve.

Rust syntax highlighting is the closest thing we have

GitHub has had Gleam syntax highlighting for 4-5 years now.

Int vs float consideration

Gleam is also the first quicktype target whose Int and Float are disjoint at runtime.

This is not true. Many of the supported languages do, including but not limited to Rust, Haskell, Python, Ruby, C, Elixir, Erlang, and Go.

Widening a whole number to a float is a wrong answer for Gleam, not a cosmetic one, and that shaped the one core change in this PR.

Why do you say this is the case? Rust goes much further than Gleam does in terms of splitting out its number types, so I'm surprised that using a float is considered an appropriate approach for Rust but not Gleam.

Gleam has two runtimes, Erlang and JavaScript, and each treats Int and Float differently. The types generated by this addition do not behave the same at runtime, but a round trip result will always match its source.

Generated decoders should take this into account as JSON does not have distinct integer and float types.

[lpil]

Use of aliases in this is considered an anti-pattern and is highly discouraged and may be deprecated in future. I think it is important that quicktype doesn't encode this pattern that we want to spread.

Instead in Gleam we would write the actual type without obscuring it with an alias. This is clearer and avoids the previously common problem of misunderstanding the semantics of aliases.