[typeshare] Fix untagged support broken via rebase

[naveenOnarayanan]

Description

• Support untagged that we lost via rebase

Test Plan

• Verified it locally against enums that are untagged

Revert Plan

• Revert

---

Summary by Gitar

• Fixed TypeScript codegen:
  • Untagged tuple variants in AlgebraicEnum now output direct types instead of wrapped objects in core/src/language/typescript.rs:324-329
• Version update:
  • Bumped to 1.13.3-gitar across cli/Cargo.toml, core/Cargo.toml, and Cargo.lock

---

[gitar-bot-staging]

Rules 🎸 1 action taken

Gitar Rules

🎸 PR Summary Enhancement: Description minimal (42 chars); enhanced with technical details

➖ Flaky Test Retry: All CI checks passing; no test failures detected

➖ Rule Quality Standards: No Gitar rule markdown files modified; only Rust code files changed

Code Review

Critical bugs found in TypeScript enum generation - conflates default externally-tagged enums with untagged enums.

The PR contains two commits: a version bump (benign) and a fix for "untagged support". However, the fix introduces critical bugs:

Primary Issues:

1. Incorrect type generation for default enums (Critical): The fix assumes empty tag_key means "untagged enum", but it actually means "no explicit serde(tag) attribute". Default Rust enums are externally-tagged and serialize as {"VariantName": value}, not as bare value. The generated TypeScript types will not match the actual JSON structure.

2. Missing #[serde(untagged)] parsing (Critical): The parser never checks for the untagged serde attribute, making it impossible to distinguish truly untagged enums from default externally-tagged enums.

3. Inconsistent variant handling (Critical): When tag_key is empty, Unit variants output string literals, Tuple variants output bare types, and AnonymousStruct variants output wrapped objects - all from the same enum, creating incompatible TypeScript union types.

Root Cause: The codebase conflates "no tag attribute" with "untagged enum" when these represent different serde behaviors.

Recommendations:

1. Add parsing for #[serde(untagged)] in parser.rs
2. Store untagged flag in RustEnum::Algebraic structure
3. Update TypeScript generator to distinguish default vs untagged enums
4. Add test coverage for default externally-tagged enums
5. Ensure all three variant types handle both cases consistently

The commit message says this "fixes" untagged support, but without proper untagged attribute parsing, the fix is based on incorrect assumptions about what empty tag_key represents.

Key Issues:

• Incorrect TypeScript generation for default (externally tagged) enums (core/src/language/typescript.rs:326) - critical
• Missing parsing of #[serde(untagged)] attribute (core/src/parser.rs) - critical
• Inconsistent handling of empty tag_key between variant types (core/src/language/typescript.rs:293) - critical

View All Findings

Bugs

Incorrect TypeScript generation for default (externally tagged) enums

• Location: core/src/language/typescript.rs:326-329
• Severity: critical
• Confidence: 95%

Issue: The fix changes tuple variant output to | InnerType when tag_key is empty. However, an empty tag_key doesn't necessarily mean the enum is untagged - it could be a default Rust enum (externally tagged).

Root Cause: The parser doesn't check for #[serde(untagged)] attribute. When no serde tag attribute exists, tag_key defaults to empty string, but this is ambiguous:

1. Default enum without serde attributes → serializes as { "VariantName": value } → TypeScript should be { "VariantName": Type }
2. Enum with #[serde(untagged)] → serializes as just value → TypeScript should be Type

Impact: This breaks TypeScript type generation for all default Rust enums with tuple variants. Generated types won't match actual JSON structure.

Example:

enum MyEnum { Variant(String) }  // No serde attribute

Current output: type MyEnum = | string (WRONG)
Expected output: type MyEnum = | { "Variant": string } (CORRECT)

Fix Needed:

1. Parse #[serde(untagged)] attribute in parser.rs
2. Store this info in RustEnum structure
3. Only emit | InnerType when truly untagged; otherwise emit | { "VariantName": InnerType }

Missing parsing of #[serde(untagged)] attribute

• Location: core/src/parser.rs
• Severity: critical
• Confidence: 95%

Issue: The parser checks for #[serde(tag = "...")] and #[serde(content = "...")] but doesn't check for #[serde(untagged)]. This makes it impossible to distinguish between:

1. Untagged enums: #[serde(untagged)] enum E { A(String) } → serializes as "value"
2. Default externally-tagged enums: enum E { A(String) } → serializes as { "A": "value" }

Current Behavior: Both cases result in tag_key = "", making them indistinguishable in code generation.

Impact: Language generators cannot correctly generate types for untagged enums vs default enums. The TypeScript generator currently assumes empty tag_key means untagged, which is incorrect.

Fix Needed:

1. Add function get_untagged(attrs: &[syn::Attribute]) -> bool to check for #[serde(untagged)]
2. Store this boolean in RustEnum::Algebraic struct (requires updating rust_types.rs)
3. Update all language generators to use this flag correctly

Reference: https://serde.rs/enum-representations.html - Shows 4 enum representations: externally tagged (default), internally tagged, adjacently tagged, and untagged

Inconsistent handling of empty tag_key between variant types

• Location: core/src/language/typescript.rs:293-351
• Severity: critical
• Confidence: 90%

Issue: When tag_key is empty, the three enum variant types handle it inconsistently:

1. Unit variant (line 305): Outputs | "VariantName" (string literal)
2. Tuple variant (line 328): Outputs | InnerType (no variant name)
3. AnonymousStruct variant (line 343): Outputs | { "VariantName": { fields } } (with variant name)

Impact: For the same enum type (empty tag_key), different variant types generate incompatible TypeScript types. This creates confusing and potentially broken type definitions.

Example:

enum Mixed {
    UnitVar,              // → "UnitVar"
    TupleVar(String),     // → string  (inconsistent!)
    StructVar { x: i32 }  // → { "StructVar": { x: number } }
}

These three variants should all follow the same tagging convention (all with or all without variant names).

Fix Needed: All three variant types must handle empty tag_key consistently. Since this likely represents default externally-tagged enums, all should include the variant name wrapper.

Code Quality

Comment doesn't match actual behavior

• Location: core/src/language/typescript.rs:327-327
• Severity: minor
• Confidence: 100%

Issue: The comment says "Untagged: just output the inner type directly" but empty tag_key doesn't necessarily indicate an untagged enum (see other findings).

Fix: Update comment to accurately reflect the ambiguity, or better yet, fix the underlying bug so that this truly only triggers for untagged enums.

Suggested comment: "Empty tag_key: output inner type (NOTE: this is incorrect for default externally-tagged enums - see #ISSUE)"

• Auto-apply suggestions - Allow Gitar to commit updates to this branch

_{Was this helpful? React with 👍 / 👎 | This comment will update automatically (Docs)}