derive Type on serde from/try_from helpers (specta rc.24 fix)#5
Merged
Conversation
specta-rc.24's serde-phase validation traverses `serde(from = ...)` / `serde(try_from = ...)` and refuses to derive Type unless the helper structs themselves implement Type. Adds the derive on the internal helpers (DeserializeFeatureHelper, DeserializeFeatureCollectionHelper, RawGeometry, GeometryType, FeatureType, FeatureCollectionType) with `#[specta(inline)]` so they don't get separately exported in TS bindings. Cfg-gates `#[serde(expecting = "...")]` on Id and RawGeometry under the specta feature -- specta-rc.24's macro parser trips on `expecting`, but it only affects error-message UX so cfg-gating it preserves runtime behavior when specta is off and skips the trip when specta is on. Two tests that asserted on the cfg-gated error messages get the assertion cfg-gated to match. All 98 unit + 16 integration + 37 doctest pass under both default features and `--features specta`. No deserialization regression -- the helper-based round-tripping still works exactly as before; specta just sees the helpers exist and is satisfied.
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
Follow-up to #3. With specta 2.0.0-rc.24, the workspace's serde-phase validation traverses
serde(from = ...)/serde(try_from = ...)helpers and refuses to deriveTypeunless the helper structs themselves implementType. This was blocking fltsci/fltsci from depending on this fork withfeatures = ["specta"]enabled.The fix keeps the helper-based deserialization intact while satisfying specta:
#[derive(specta::Type)]+#[specta(inline)]to the internal helper types:DeserializeFeatureHelper,DeserializeFeatureCollectionHelper,RawGeometry,GeometryType,FeatureType,FeatureCollectionType. Theinlineflag means specta knows about them but doesn't emit separate TS exports.#[serde(expecting = "...")]onIdandRawGeometryunder the specta feature -- rc.24's macro parser trips onexpecting. The attribute only affects error-message UX, so cfg-gating it preserves runtime behavior when specta is off and skips the trip when specta is on. Two tests that asserted on the cfg-gated error messages get the assertion cfg-gated to match.Test results
--features spectaNo deserialization regression -- the helper-based round-tripping (with all its existing validation: tag enum check, foreign-members normalization, etc.) still works exactly as before. Specta just sees the helpers exist and is satisfied.
Why this beats the closed #4
#4 dropped the helpers entirely and accepted 18 deserialize-test regressions. That broke geometry round-trip in real ways (foreign_members greedily caught variant fields). This PR keeps the helpers, so deserialization is unchanged, and only adds metadata for specta to consume.