Feature request: Panic On Unknown Serde Attribute

[mcmah309]

Currently when an unknown serde attribute is encountered a warning is emitted. There is also no-serde-warnings which suppresses the warning, but really what I want to happen is that it fails to compile to tell me about this issue.

There should be a new flag panic-on-unknown-serde (or strict-serde) where it panics when an attribute is unknown. This can save hours of debugging.

[gustavo-shigueo]

Hi @mcmah309, thanks for opening an issue. This wouldn't be too hard to implement, but wouldn't it be too intrusive/annoying? What we call an "unknown serde attribute" is not an invalid attribute according to serde (as that would be a serde compiler error), it's just a completely valid serde attribute that ts-rs doesn`t parse, while this annoyance would be mitigated by being gated by a feature flag, it still sounds very heavy handed, as then users that enable this flag would be forbidden from using serde attributes that ts-rs doesn;t parse.

Can you show an example of where this has caused problems/confusion so we can understand the issue better?

[gustavo-shigueo]

users that enable this flag would be forbidden from using serde attributes that ts-rs doesn;t parse.

As of today, this would forbid (at least) the following serde attributes:

• #[serde(transparent)]
• #[serde(from = "FromType")]
• #[serde(try_from = "FromType")]
• #[serde(into = "IntoType")]
• #[serde(expecting = "...")]
• #[serde(variant_identifier)]
• #[serde(field_identifier)]
• #[serde(alias = "name")]
• #[serde(skip_deserializing)]
• #[serde(serialize_with = "path")]
• #[serde(deserialize_with = "path")]
• #[serde(borrow)] (see Parse #[serde(borrow)] to not emit warnings #471)
• #[serde(borrow = "'a + 'b + ...")] (see above)
• #[serde(other)]
• ``#[serde(getter = "...")]`

[mcmah309]

I am currently using this crate for Rust to Js communication over Json. The issue with the current implementation is that one could add many of those flags and now the shape of the Ts generated is different than what would be sent over the wire, causing bugs. I would rather know that with strict-serde enabled, the shape of the Ts and Rs match such that I can serialize messages back and forth.

users that enable this flag would be forbidden from using serde attributes that ts-rs doesn;t parse.

Yes that would be expected. If they want otherwise, they could turn it off.

[gustavo-shigueo]

I see, I'll make a PR on that this weekend, the annoying part will be the CI test for --all-features, as that will trigger both this and no-serde-warnings

[mcmah309]

That would be awesome thanks!

the annoying part will be the CI test for --all-features, as that will trigger both this and no-serde-warnings

In order for things to compile correctly, if you still want to support all the flags, maybe surprisingly if no-serde-warnings and strict-serde are both enabled then strict-serde should actually not function. Since if it was the other way around, a crate on the dependency graph may compile with no-serde-warnings but fail with strict-serde. Since features are supposed to be additive. i.e. If two different crates in the same dependency graph depend on ts-rs, and one enables one feature while the other enables the other feature, Cargo compiles ts-rs once with both features enabled. You could still handle this by printing a warning in the build.rs of this crate. Just check if both features are enabled from the env variable cargo sets (CARGO_FEATURE_<name>). If both are enabled print a cargo::warning and the proper behavior should probably be allow compilation but still print warnings (having both strict-serde and no-serde-warnings enabled has no effect).

[NyxCode]

If we eventually get the diagnostics API, then I think one could just slap #[deny(ts_rs::UnknownAttribute)] or something on the struct. Or we could emit it as a deny-by-default lint, and users could add a #[allow(ts_rs::UnknownAttribute)].
Let's hope we get #54140 in 2026 ^^

[mcmah309]

That’s an interesting idea. We could do something like that today. Just have an attribute to suppresses any warnings and another to treat them as compile time errors. That would make things a lot more composable and explicit.