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
I've been using this library for a while on multiple projects now, and I've found myself wanting to set a default export_to location once in a config or at the top of a given lib.rs file (or similar) - maybe a Cargo.toml file would be best?
Especially when working in cargo workspaces, it would be nice to configure ts-rs so it will export all interfaces into a single directory/file. Having many (>10) export_to=".."s is very verbose and error-prone.
Description of my case:
I've been working with SvelteKit a lot recently, you can only define one import-alias directory/file. I use @bindings to point to the bindings directory generated by the library. And due to SvelteKit's limitations I can only point it to a single directory. But when defining types in multiple library crates, this makes the user experience worse.
The text was updated successfully, but these errors were encountered:
@NyxCode What are your thoughts on adding an environment variable that is parsed as default config directly. Cant really think of a better option off the top of my head. I'd be happy to implement this request in that way.
Hey,
I've been using this library for a while on multiple projects now, and I've found myself wanting to set a default
export_to
location once in a config or at the top of a givenlib.rs
file (or similar) - maybe aCargo.toml
file would be best?Especially when working in cargo workspaces, it would be nice to configure
ts-rs
so it will export all interfaces into a single directory/file. Having many (>10)export_to=".."
s is very verbose and error-prone.Description of my case:
I've been working with SvelteKit a lot recently, you can only define one import-
alias
directory/file. I use@bindings
to point to thebindings
directory generated by the library. And due to SvelteKit's limitations I can only point it to a single directory. But when defining types in multiple library crates, this makes the user experience worse.The text was updated successfully, but these errors were encountered: