Fields with skip_deserializing not getting exported?

[ghost]

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!

[carlocorradini]

Same problem here!

Why this decision? 🙃

[escritorio-gustavo]

Hey @NyxCode, is this intended behavior?

[NyxCode]

@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.

[NyxCode]

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.

[escritorio-gustavo]

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

[NyxCode]

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.