Fields with `skip_deserializing` not getting exported?
andre-volvo opened this issue · 6 comments
Hello!
Thanks for the great crate, I find it very useful!
I'm just wondering if there's a reason why fields marked with #[serde(skip_deserializing)] are getting skipped? I saw in the macro code that this is a deliberate decision, but I fail to see the reasoning behind it.
As exporting types are in essence serializing them, I would logically assume that the bindings would still include those fields.
Best regards!
Same problem here!
Why this decision? 🙃
Hey @NyxCode, is this intended behavior?
@escritorio-gustavo
I think it is, but it's a bit tricky!
My use-case are mostly HTTP APIs. There, I'd want "skip_serializing" to skip the field when my TS is receiving data, and "skip_deserializing" to skip the field if my TS is sending data.
One alternative I can see to the current behaviour (skip if "skip_serializing" or "skip_deserializing" is present) is to just ignore "skip_serializing" and "skip_deserializing" entirely. That's definetely a step forward, since you can then still skip the field with #[ts(skip)], but right now, there's no way to "un-skip" it.
There might be usecases where it'd be nice to get both variants - like in the REST API example above.
So I think the best way forward is to just ignore "skip_serializing" and "skip_deserializing" for now. Happy to be convinced of something else tho.
Yeah, the fact that the data can go both from TS to Rust and from Rust to TS makes this a lot more complicated.
As far as I can tell the only way around it is to ignore both attributes as you proposed and rely on #[ts(skip)] and #[serde(skip)], but that is probably a breaking change for a lot of people, so a major version bump is probably required to implement this
Agreed!
Let's keep track of changes, e.g in a CHANGELOG.md, so we can create a GitHub release with a migration guide on the next release.