I was running into an issue yesterday with adjacently tagged enums. If you have something like:

#[derive(Debug, Serialize, Deserialize, Tsify)]
#[serde(tag = "reason", content = "inner")]
pub enum ParseBaseUriError {
    MissingTrailingSlash,
    ...
}

Then the generated types have the following structure

declare namespace ParseBaseUriError {
    export type MissingTrailingSlash = { reason: "MissingTrailingSlash"; inner: null };
    ...

The issue here is that the type suggests inner must be null, where in my testing, serializing these objects just leaves the field as undefined.

I've got a branch where I've written a potential fix, but I have a feeling it might be quite hacky and I may not understand the reasoning behind picking null originally. Is there a reason why this library chooses null for unit types rather than undefined? I tried thinking about this and I'm not sure which one I'd pick, as I suspect neither map perfectly.

That branch makes inner optional, while keeping the value of null. If that seems sensible I'm happy to open a PR.

In the mission of creating a cleaner typescript api for my own library, i updated the code of this lib to emit enums as namespaces of types. Therefore each enum option now has its own type declaration and the union type is created from those types. For example:

declare namespace GenericEnum {
    export type GenericEnumUnit = "Unit";
    export type GenericEnumNewType<T> = { NewType: T };
    export type GenericEnumSeq<T, U> = { Seq: [T, U] };
    export type GenericEnumMap<T, U> = { Map: { x: T; y: U } };
}

export type GenericEnum<T, U> = GenericEnum.GenericEnumUnit | GenericEnum.GenericEnumNewType<T> | GenericEnum.GenericEnumSeq<T, U> | GenericEnum.GenericEnumMap<T, U>;

I also introduced the enum_reimport_module option to further cleanup the namespace using a little "hack", since you cannot import inside the module. With this option the internal enum looks like this:

#[derive(Tsify)]
#[tsify(enum_reimport_module)]
enum Internal {
    Struct { x: String, y: i32 },
    EmptyStruct {},
    Tuple(i32, String),
    EmptyTuple(),
    Newtype(Foo),
    Unit,
}

without enum_reimport_module:

declare namespace Internal {
    export type InternalStruct = { Struct: { x: string; y: number } };
    export type InternalEmptyStruct = { EmptyStruct: {} };
    export type InternalTuple = { Tuple: [number, string] };
    export type InternalEmptyTuple = { EmptyTuple: [] };
    export type InternalNewtype = { Newtype: Foo };
    export type InternalUnit = "Unit";
}

export type Internal = Internal.InternalStruct | Internal.InternalEmptyStruct | Internal.InternalTuple | Internal.InternalEmptyTuple | Internal.InternalNewtype | Internal.InternalUnit;

with enum_reimport_module:

import type * as Internal_Module from "./tsify";
declare namespace Internal {
    export type Struct = { Struct: { x: string; y: number } };
    export type EmptyStruct = { EmptyStruct: {} };
    export type Tuple = { Tuple: [number, string] };
    export type EmptyTuple = { EmptyTuple: [] };
    export type Newtype = { Newtype: Internal_Module.Foo };
    export type Unit = "Unit";
}

export type Internal = Internal.Struct | Internal.EmptyStruct | Internal.Tuple | Internal.EmptyTuple | Internal.Newtype | Internal.Unit;

When you have a recursive enum such as Foo here:

use tsify::Tsify;
use serde::{Serialize, Deserialize};

#[derive(Tsify)]
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase", deny_unknown_fields)]
pub struct OneOf<T> {
    one_of: Vec<T>,
}

#[derive(Tsify)]
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
pub struct Bar {}

#[derive(Tsify)]
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
#[serde(untagged)]
pub enum Foo {
    OneOfFoo(OneOf<Foo>),
    Bar(Bar),
}

then the generated Typescript bindings fail to compile

type __FooBar = Bar;
type __FooFoo = Foo;
type __FooOneOf<A> = OneOf<A>;
declare namespace Foo {
    export type OneOfFoo = __FooOneOf<__FooFoo>;
    export type Bar = __FooBar;
}

export type Foo = Foo.OneOfFoo | Foo.Bar;

export interface Bar {}

export interface OneOf<T> {
    oneOf: T[];
}

Due to TS2456: Type alias 'Foo' circularly references itself.

This does not happen if the type was just

export type Foo = OneOf<Foo> | Bar

I assumed #[serde(untagged)] would provide that but it seems not?

Hi! thanks for creating this library. As the title says, it seems not to work for return types if the exported bindgen function is async. This error shows:

the trait bound `wasm_bindgen::JsValue: From<MyStruct>` is not satisfied

If I make the function non async, it works. For parameters it always works.

Discovered another strange edge-case today, see the following:

#[test]
fn test_flatten_optional() {
    #[derive(Tsify)]
    struct A {
        a: i32,
        b: String,
    }

    #[derive(Tsify)]
    struct B {
        #[tsify(optional)]
        #[serde(flatten)]
        extra: Option<A>,
        c: i32,
    }

    assert_eq!(
        B::DECL,
        indoc! {""}
    );
}

You get the generated type:

export interface B extends A | null {
    c: number;
}

which is invalid.

I suspect the way to solve this would be for B to become a type and to use & instead of extends so you could do something like:

type B = {

} & (A | {})

I'm not sure of a way to express this using interfaces, so I suspect this would be a pretty substantial change.

If you have a type like this:

#[derive(Tsify)]
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
pub struct Foo<T> {
    #[tsify(type = "[T, ...T[]]")]
    bar: Vec<T>,
}

then the generated binding looks like this:

export interface Foo {
    bar: [T, ...T[]];
}

when I would have expected it to be

export interface Foo<T> {
    bar: [T, ...T[]];
}

(and just for clarity, if you don't use the type = macro then it looks like):

export interface Foo<T> {
    bar: T[];
}

Hello, I was just wondering if it's possible to decouple this from wasm_bindgen.

I understand that the original purpose of the library was to focus on wasm_bindgen but I was wondering if this could become a more generalised library for creating cross-language type definitions, similar to https://github.com/1Password/typeshare

I was trying to switch ("match style") over enum cases with fields, but this seems not to be possible. Example (src):

type AppEvent =
  | { kind: "click"; x: number; y: number }
  | { kind: "keypress"; key: string; code: number }
  | { kind: "focus"; element: HTMLElement };

function handleEvent(event: AppEvent) {
  switch (event.kind) {
    case "click":
      // We know it is a mouse click, so we can access `x` and `y` now
      console.log(`Mouse clicked at (${event.x}, ${event.y})`);
      break;
    case "keypress":
      // We know it is a key press, so we can access `key` and `code` now
      console.log(`Key pressed: (key=${event.key}, code=${event.code})`);
      break;
    case "focus":
      // We know it is a focus event, so we can access `element`
      console.log(`Focused element: ${event.element.tagName}`);
      break;
  }
}

Potential feature request, or maybe it's already possible and I'm missing something?

If you have an enum such as this:

#[derive(Debug, Serialize, Deserialize, Tsify)]
#[serde(tag = "reason")]
pub enum ParseBaseUriError {
    MissingTrailingSlash,
    UrlParseError(String),
    CannotBeABase,
}

then the generated types look as follows:

declare namespace ParseBaseUriError {
    export type MissingTrailingSlash = { reason: "MissingTrailingSlash" };
    export type UrlParseError = { reason: "UrlParseError" } & string;
    export type CannotBeABase = { reason: "CannotBeABase" };
}

And I believe UrlParseError is unsatisfiable.

I don't really have a good suggestion for how to resolve this, perhaps disallowing new-type like variants, or possibly only ones that contain types that can be mapped to a non-object JS type. For now I have resolved this by picking a different tagging mechanism, or turning the variants into structs, but I thought I'd flag in case there are any other ideas or to allow adding a warning.

I've just tried out this crate and the typescript interfaces it's creating are awesome. Unfortunately I don't seem to be able to use it in methods like

#[wasm_bindgen]
modify_some_object(my_wasm_obj: &mut MyWasmObj); 

as tsify(into_wasm_abi, from_wasm_abi) doesn't implement support for RefFromWasmAbi and RefMutFromWasmAbi

Is there any plan to support deriving impl's for these?