Skip to content

Releases: polyvariant/smithy4s-ndjson

v0.3.2

Choose a tag to compare

@kubukoz kubukoz released this 29 Sep 00:35
4605f3d

What's Changed

Full Changelog: v0.3.1...v0.3.2

v0.3.1 — Scala Native support

Choose a tag to compare

@kubukoz kubukoz released this 27 Aug 00:21
v0.3.1
59b0679

First release with Scala Native support, and the first complete one in the 0.3 line — v0.3.0 shipped without smithy4s-ndjson-protocol and should not be used.

Scala Native

smithy4s-ndjson-core and smithy4s-ndjson-http4s are now cross-built for Scala Native 0.5 alongside the JVM (#9). No source changes were needed — the full suite passes on Native exactly as written.

libraryDependencies += "org.polyvariant" %%% "smithy4s-ndjson-http4s" % "0.3.1"

The protocol artifact stays a single platform-independent Java jar, as before; it reaches your codegen model path automatically through core's manifest, on Native as on the JVM.

Fixes

  • smithy4s-ndjson-protocol is published again (#10). In 0.3.0 it was aggregated from rootJVM rather than the root tlCiRelease publishes from, so it silently dropped out of the release while CI stayed green.
  • Native binary compatibility is now checked by MiMa against the 0.3.0 baseline.

Artifacts

Artifact JVM Native 0.5
smithy4s-ndjson-core ✅ ✅
smithy4s-ndjson-http4s ✅ ✅
smithy4s-ndjson-protocol platform-independent Java jar

Full changelog: v0.2.1...v0.3.1

v0.3.0 — cross-build to Scala Native (incomplete, use 0.3.1)

Choose a tag to compare

@kubukoz kubukoz released this 27 Aug 00:20
v0.3.0
9f3093b

Warning

This release is incomplete — use v0.3.1 instead.

smithy4s-ndjson-protocol was not published in 0.3.0, but smithy4s-ndjson-core's smithy4sDependencies manifest entry points at it. A build depending on 0.3.0 will fail to resolve the protocol trait onto its codegen model path. Fixed in 0.3.1 (#10).

Scala Native support

smithy4s-ndjson-core and smithy4s-ndjson-http4s are now cross-built for Scala Native 0.5 alongside the JVM (#9). No source changes were needed — the full test suite passes on Native as written.

libraryDependencies += "org.polyvariant" %%% "smithy4s-ndjson-http4s" % "0.3.1"

Again: take 0.3.1, not this release.

v0.2.1 — interpret every trait simpleRestJson does

Choose a tag to compare

@kubukoz kubukoz released this 19 Aug 19:36
v0.2.1
427b0bb

The fix

ndjsonRestJson's @protocolDefinition list named only 11 of the 28 traits alloy#simpleRestJson declares. That list isn't documentation — Protocol.hintMask is derived from it, and the interpreter builds its JSON codecs from that mask. So the 17 missing traits were silently ignored on every body, unary payloads and NDJSON elements alike.

Silently is the operative word: nothing errored. A @timestampFormat("date-time") member was written as an epoch number instead of an RFC-3339 string, and @jsonName reverted to the member name. The first sign was a decode failure on the far side of the wire, against a body that looked reasonable.

Traits that were being dropped:

smithy.api timestampFormat, jsonName, httpResponseCode, length, pattern, range
alloy uuidFormat, discriminated, nullable, untagged, jsonUnknown, openEnum, durationSecondsFormat, dateFormat, localTimeFormat, offsetDateTimeFormat, preserveKeyOrder

The codec stack already handled all of them — it's smithy4s's own, shared with SimpleRestJsonBuilder. Only the declaration was short. The list is now simpleRestJson's verbatim, plus @streaming.

⚠️ This changes bytes on the wire

If your model uses any trait in that table, your JSON changes — to what the protocol always promised. A @timestampFormat("date-time") member that 0.2.0 wrote as 1767225600 now writes "2026-01-01T00:00:00Z".

Binary compatibility is unaffected (MiMa passes), but binary compatibility doesn't imply behavioural compatibility. If you have a peer built against 0.2.0's output — a hand-written client, a recorded fixture, a stored payload — check it before upgrading. If you use none of those traits, this is a no-op.

Guarding it

  • ProtocolTraitsTests asserts the trait set against alloy.SimpleRestJson.protocol.traits directly, not against a hand-copied list — so alloy adding a trait fails the build instead of drifting quietly back into this bug.
  • A new Formats fixture operation proves it end to end, exercising @timestampFormat and @jsonName on a unary input and a streamed element within one call.

Full changelog: v0.2.0...v0.2.1

v0.1.1

Choose a tag to compare

@kubukoz kubukoz released this 19 Aug 01:49
2b32c82

What's Changed

  • Remove the asInstanceOf, and reframe authorization as one middleware use among several by @kubukoz in #2
  • Frame streamed bodies by shape, in both directions by @kubukoz in #4

Full Changelog: v0.1.0...v0.1.1