`#[declare(...)]` accepts arguments on a type alias and ignores them

[madonoharu]

#[declare] takes arguments and forwards them for a struct or an enum. On a type alias it accepts them and drops them.

Reproducing

On 396867b:

#[declare(rename = "RenamedStruct")]
#[derive(Serialize, Deserialize)]
pub struct S { pub a: u32 }

#[declare(rename = "RenamedAlias")]
pub type A = Vec<u32>;

export interface RenamedStruct {
    a: number;
}

export type A = number[];

The struct is renamed. The alias is not, and nothing is reported — no error, no warning, no note that the attribute went nowhere.

Where it goes wrong

declare_impl in tsify-macros/src/lib.rs splits on the item kind:

match item {
    syn::Item::Type(item) => type_alias::expand(item),
    syn::Item::Enum(item) => derive::expand_by_attr(args, item.into()),
    syn::Item::Struct(item) => derive::expand_by_attr(args, item.into()),
    ...
}

expand_by_attr wraps args back into a #[tsify(...)] attribute and lets the normal parser see it. type_alias::expand takes only the item — its signature has no place for args — and builds its TypeContext from TypeGenerationConfig::default(), so container attributes do not reach the alias path at all.

Why it matters beyond rename

A type alias currently has no attribute surface whatsoever. That is also why there is no way to override a reference inside an alias the way #[tsify(type = "...")] overrides one in a field. Plumbing args through would close both.

Whatever the fix, an argument that cannot be honoured should be an error rather than silence.

Notes

Found while looking for the escape hatch a type alias would need for #103. Independent of it — this is about an attribute that is accepted and ignored today.