You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, having multiple types with the same name is problematic.
Firstly, with just #[ts(export)], they will just overwrite eachother. This can be worked around with #[ts(export_to = "..")].
Then, when a third type depends on two types with the same name, the generated imports for the third type will be invalid. This can be worked around with #[ts(rename = "..")].
How can we improve on this? Resolving these conflicts would require coordination between different invocations of derive(TS).
I don't like to reintroduce something like export! to which you pass each type you wish to export, since this gets really painfull when working with a deep module tree, requiring you to make everything public.
The text was updated successfully, but these errors were encountered:
yeah I've just stumbled upon this problem in my project, would be nice if you could have "export_to_dir=..." parameter so that you can namespace your conflicting names
Yeah, I'm also stumbling on this. For my use case it would be sufficient if the module an exported type was located in was taken into account (e.g., each mod became its own directory). Granted, not sure how possible/straightforward that would be
Currently, having multiple types with the same name is problematic.
Firstly, with just
#[ts(export)]
, they will just overwrite eachother. This can be worked around with#[ts(export_to = "..")]
.Then, when a third type depends on two types with the same name, the generated imports for the third type will be invalid. This can be worked around with
#[ts(rename = "..")]
.How can we improve on this? Resolving these conflicts would require coordination between different invocations of
derive(TS)
.I don't like to reintroduce something like
export!
to which you pass each type you wish to export, since this gets really painfull when working with a deep module tree, requiring you to make everything public.The text was updated successfully, but these errors were encountered: