Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Recursive Affixes on Types #28

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

cwfitzgerald
Copy link

@cwfitzgerald cwfitzgerald commented Jul 20, 2023

Motivation

I have a project which is a rust component in a larger typescript codebase. We are using Tsify to create strongly typed bindings to our various methods. However, as we are dealing with similar concepts on both sides, we run into a lot of type name conflicts between exported-rust types and typescript native types. We want to prefix all of the types exported from our rust codebase so that it's clear that the given type is coming from the rust bundle. To facilitate this, without needing to prefix all of actual rust types, we have added two attributes to the tsify macro.

Attributes

The new attributes are type_prefix and type_suffix which work recursively.

#[derive(Tsify)]
#[tsify(type_prefix = "Blah")]
struct SomeType {
    a: u32,
    b: OtherType,
}

will generate:

interface BlahSomeType {
    a: number;
    b: BlahOtherType;
}

We will put this attribute on all of our types and then all of our bindings will use custom types that are prefixed by the given prefix.

Alternatives

As derive macros can't really have global configuration, this seems like the best way to do this on a global scale.

We tried using #[serde(rename = "...")] combined with #[tsify(type = "...")] but it becomes extremely tedious and error prone as soon as you have a lot of nested structs because the type annotation does no verification you didn't put the wrong type, and you need to spell out all the components of complex types.

Comments

The code change is a little large as it passes the configuration through to formerly pure functions, but this perfectly sets us up for things like #26 and other type-gen options.

TODO

I haven't done this in case we want to discuss the design more, but once it's solidified, I'll add to the readme.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant