Language in practice

[oscartbeaumont]

Language:

• By have the user parse in a T: Language we can instantly support any language. This was the core idea.
• In practice this only works for languages like Typescript where the type system is losse because if it's fixed you require extra logic than just the types (Eg. impl Procedure for U in rspc`)

LanguageExt:

• Tauri Specta deals with this by introducing Language: LanguageExt but this means the user has to add specta_typescript and enable the typescript feature on Tauri Specta which leads to a worse UX imo.
• This can be pared with reexporting from the library to solve the DX problem.

my_library::TypeCollection (wrapping the langauge fully):

• The user must enable a feature for each language on the library.
• This also requires code related to file saving, formatting, etc but it does give the library full control over the exporting process.
• In practice this is flawed cause it doesn't expose the language configuration to the user.

Given this the question becomes should Language continue to exist in Specta's core? If TypeCollection is in the core we can't expose features for each language due to it causing a cyclic dependency.

My proposal

What if we flip this entire process.

Changes:

• Introduce specta_typescript::Typescript::export and specta_typescript::Typescript::export_to. Eg. Typescript::default().export_to(type_collection, path)
• Drop Language trait completely.
• Drop TypeCollection::export and TypeCollection::export_to
• The expectation is that downstream crates do their own thing.

[oscartbeaumont]

Maybe drop Typescript::framework_header