refactor: taurpc to use specta v2.0.0-rc.23

[AndreRoelofs]

Specta is preparing for 2.0.0 release and just released breaking api changes with v2.0.0-rc.23. The full changes can be found here.

I will use it in my own project for now as the changes are vast

Here's a breakdown of the changes:

• bump taurpc to 0.8.0 and update the readme
• constrain tauri to 2.10.* to support new specta
• bump specta to v2.0.0-rc.23 and specta-typescript to 0.0.10
• enable the new collect feature flag (renamed from export)
• remove the function feature from specta-typescript (no longer exists)
• replace FunctionResultVariant with FunctionReturnType
• replace ts::datatype() with ts::primitives::inline() and ts::primitives::reference() for correct type rendering
• handle TAURI_CHANNEL as a special-case opaque reference since specta-typescript doesn't know how to export it
• remove type_map.remove() call for Channel (method no longer exists in TypeCollection)
• remove framework_header splitting logic and .format() call (both removed from specta-typescript)
• filter out specta's auto-generated TAURI_CHANNEL typedef since we define our own type alias
• use named references in function signatures instead of inlining full struct definitions
• remove stale .formatter(specta_typescript::formatter::prettier) comment (formatter integration removed in rc.23)

What is left:

• Provide a linting guide integration for bindings.ts in order to prevent needless git history.
• Conclude testing in a real project

[oscartbeaumont]

I suspect this might be superseded by #58 which as well as upgrading the Specta version also refactors TauRPCs logic use Specta's new exporter API instead of the primitives. This allows supporting features such as multi-file exporting, branded types and more which I don't think would work with this PRs implementation.

[AndreRoelofs]

Oh apologies. I saw that PR dated in 2025 so didn't check the latest commits.

Yes I put this onto draft because I wasn't really happy with the implementation as it was not using the Specta api correctly, and wanted to use it as just 23 baseline until a later refactoring.

But if you're working on your own version then please go ahead, I will close this pr and use it temporarily in my own project as it does work.

Out of curiosity - what did you decide regarding the linter? I know specta disabled it but at least in my case that kind of feature is super useful because I want to avoid polluting git history because of some unexpected format changes in the bindings file.

[oscartbeaumont]

Out of curiosity - what did you decide regarding the linter? I know specta disabled it but at least in my case that kind of feature is super useful because I want to avoid polluting git history because of some unexpected format changes in the bindings file.

I personally found that having an official integration wasn't very good because for an sufficiently advanced JS monorepo I would end up having to build my own formatter hook anyway as the default just wasn't quite right. By the time your building your own integration it's better for Specta to just not get involved and not risk breaking changes in the API surface.

My recommendation is to just use std::process::Command and call your formatter after you do the regular Specta export. That being said that recommendation makes way more sense with Specta directly, Tauri Specta and rspc as you manually do the type export, for TauRPC (from memory) it's implicitly done so you won't be able to time that very well. I am quite happy for TauRPC to copy the code from Specta's old core and ship and equivalent feature, something more opinionated like this I think belongs in the framework so this would be super resonable although I do have the same worries that the generic hooks aren't applicable in enough usecases (although i'm sure with enough thought they could be done is a solid way).

[AndreRoelofs]

Ok thanks for the explanation. I will think about it more. I'm glad we agree that it makes more sense for this library as opposed to Specta due to higher specialization.