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

How to handle naming conflicts #54

Open
NyxCode opened this issue Nov 12, 2021 · 3 comments · May be fixed by #304
Open

How to handle naming conflicts #54

NyxCode opened this issue Nov 12, 2021 · 3 comments · May be fixed by #304

Comments

@NyxCode
Copy link
Collaborator

NyxCode commented Nov 12, 2021

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.

@Niedzwiedzw
Copy link
Contributor

Niedzwiedzw commented Nov 25, 2021

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

@Niedzwiedzw
Copy link
Contributor

(my code is autogenerated by diesel so I cannot really specify full paths)

@ajmcquilkin
Copy link

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

@NyxCode NyxCode linked a pull request May 17, 2024 that will close this issue
12 tasks
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 a pull request may close this issue.

3 participants