specta: emit Feature.properties via named JsonValue alias#8
Merged
Conversation
Workaround for specta-rc.24's broken `serde_json::Value` Type impl,
which is `inline: true` and recursive (`Vec<Value>`, `Map<String,
Value>`). Inline + recursive means the export pass filters the type
out (since `inline: true` makes `requires_reference` return false),
so consumers see references to an undefined `Value` name in TS.
Add `geojson::specta_compat::JsonValue` -- a manual `specta::Type`
that emits a top-level recursive alias:
export type JsonValue =
| null
| boolean
| number
| string
| JsonValue[]
| { [key: string]: JsonValue };
Override Feature.properties (and its DeserializeFeatureHelper
counterpart) to use it. Runtime serde behavior is unchanged.
External downstream crates can use the same type to override their
own `serde_json::Value` fields, since the recursive-inline bug
affects every consumer, not just geojson.
specta-rc.24's `serde_json::Number` Type impl emits a tagged union
of `{ f64 } | { i64 } | { u64 }` even though the wire shape is just
a JSON number. Override at the variant level so untagged `Id` lands
as `string | number` in TS, matching its actual runtime shape.
Runtime serde behavior is unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two specta-rc.24 typegen workarounds that downstream consumers
(specifically fltsci/fltsci) depend on:
geojson::specta_compat::JsonValue-- a named TS recursivealias for
serde_json::Value. specta-rc.24's default impl isinline: trueAND recursive (Vec<Value>,Map<String, Value>),so the export pass filters the type out (
inline: truemakesrequires_referencereturn false) and consumers see references toan undefined
Valuename. The new type emits asvia
init_with_sentinel+specta_typescript::define(). The Rusttype is a placeholder (never instantiated) and only used through
#[specta(type = ::geojson::specta_compat::JsonValue)]overrides.Feature.propertiesis wired up here; downstreams can use thesame type for any of their own
serde_json::Valuefields.Id::Numberflatten --serde_json::Number's rc.24 Type implemits a tagged
{ f64 } | { i64 } | { u64 }union even though thewire shape is just a JSON number.
#[specta(type = f64)]on theNumbervariant restores the flatstring | numberTS shape thatmatches
Id's#[serde(untagged)]runtime behavior.Runtime serde behavior is unchanged on both fronts -- only the
typegen view is affected. Both workarounds are scoped so they can
peel back when specta-rc.24 (or its replacement) fixes the
underlying type-graph emission.
Test plan
cargo check --features spectacleangreen against this rev