Skip to content

chore(deps): update [backend] update dependencies#524

Open
renovate[bot] wants to merge 1 commit intodevelopfrom
renovate/backend-update-dependencies
Open

chore(deps): update [backend] update dependencies#524
renovate[bot] wants to merge 1 commit intodevelopfrom
renovate/backend-update-dependencies

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate bot commented Jan 4, 2026

This PR contains the following updates:

Package Type Update Change
reqwest workspace.dependencies minor 0.12.90.13.0
specta workspace.dependencies patch =2.0.0-rc.22=2.0.0-rc.24
specta-typescript workspace.dependencies patch 0.0.90.0.11
tauri-plugin-single-instance workspace.dependencies patch 2.4.02.4.1
tauri-specta workspace.dependencies patch =2.0.0-rc.21=2.0.0-rc.24

Release Notes

seanmonstar/reqwest (reqwest)

v0.13.2

Compare Source

  • Fix HTTP/2 and native-tls ALPN feature combinations.
  • Fix HTTP/3 to send h3 ALPN.
  • (wasm) fix RequestBuilder::json() from override previously set content-type.

v0.13.1

Compare Source

  • Fixes compiling with rustls on Android targets.

v0.13.0

Compare Source

  • Breaking changes:
    • rustls is now the default TLS backend, instead of native-tls.
    • rustls crypto provider defaults to aws-lc instead of ring. (rustls-no-provider exists if you want a different crypto provider)
    • rustls-tls has been renamed to rustls.
    • rustls roots features removed, rustls-platform-verifier is used by default.
      • To use different roots, call tls_certs_only(your_roots).
    • native-tls now includes ALPN. To disable, use native-tls-no-alpn.
    • query and form are now crate features, disabled by default.
    • Long-deprecated methods and crate features have been removed (such as trust-dns, which was renamed hickory-dns a while ago).
  • Many TLS-related methods renamed to improve autocompletion and discovery, but previous name left in place with a "soft" deprecation. (just documented, no warnings)
    • For example, prefer tls_backend_rustls() over use_rustls_tls().

v0.12.28

  • Fix compiling on Windows if TLS and SOCKS features are not enabled.

v0.12.27

  • Add ClientBuilder::windows_named_pipe(name) option that will force all requests over that Windows Named Piper.

v0.12.26

  • Fix sending Accept-Encoding header only with values configured with reqwest, regardless of underlying tower-http config.

v0.12.25

  • Add Error::is_upgrade() to determine if the error was from an HTTP upgrade.
  • Fix sending Proxy-Authorization if only username is configured.
  • Fix sending Proxy-Authorization to HTTPS proxies when the target is HTTP.
  • Refactor internal decompression handling to use tower-http.

v0.12.24

  • Refactor cookie handling to an internal middleware.
  • Refactor internal random generator.
  • Refactor base64 encoding to reduce a copy.
  • Documentation updates.

v0.12.23

  • Add ClientBuilder::unix_socket(path) option that will force all requests over that Unix Domain Socket.
  • Add ClientBuilder::retry(policy) and reqwest::retry::Builder to configure automatic retries.
  • Add ClientBuilder::dns_resolver2() with more ergonomic argument bounds, allowing more resolver implementations.
  • Add http3_* options to blocking::ClientBuilder.
  • Fix default TCP timeout values to enabled and faster.
  • Fix SOCKS proxies to default to port 1080
  • (wasm) Add cache methods to RequestBuilder.

v0.12.22

  • Fix socks proxies when resolving IPv6 destinations.

v0.12.21

  • Fix socks proxy to use socks4a:// instead of socks4h://.
  • Fix Error::is_timeout() to check for hyper and IO timeouts too.
  • Fix request Error to again include URLs when possible.
  • Fix socks connect error to include more context.
  • (wasm) implement Default for Body.

v0.12.20

  • Add ClientBuilder::tcp_user_timeout(Duration) option to set TCP_USER_TIMEOUT.
  • Fix proxy headers only using the first matched proxy.
  • (wasm) Fix re-adding Error::is_status().

v0.12.19

  • Fix redirect that changes the method to GET should remove payload headers.
  • Fix redirect to only check the next scheme if the policy action is to follow.
  • (wasm) Fix compilation error if cookies feature is enabled (by the way, it's a noop feature in wasm).

v0.12.18

  • Fix compilation when socks enabled without TLS.

v0.12.17

  • Fix compilation on macOS.

v0.12.16

  • Add ClientBuilder::http3_congestion_bbr() to enable BBR congestion control.
  • Add ClientBuilder::http3_send_grease() to configure whether to send use QUIC grease.
  • Add ClientBuilder::http3_max_field_section_size() to configure the maximum response headers.
  • Add ClientBuilder::tcp_keepalive_interval() to configure TCP probe interval.
  • Add ClientBuilder::tcp_keepalive_retries() to configure TCP probe count.
  • Add Proxy::headers() to add extra headers that should be sent to a proxy.
  • Fix redirect::Policy::limit() which had an off-by-1 error, allowing 1 more redirect than specified.
  • Fix HTTP/3 to support streaming request bodies.
  • (wasm) Fix null bodies when calling Response::bytes_stream().

v0.12.15

  • Fix Windows to support both ProxyOverride and NO_PROXY.
  • Fix http3 to support streaming response bodies.
  • Fix http3 dependency from public API misuse.

v0.12.14

  • Fix missing fetch_mode_no_cors(), marking as deprecated when not on WASM.

v0.12.13

  • Add Form::into_reader() for blocking multipart forms.
  • Add Form::into_stream() for async multipart forms.
  • Add support for SOCKS4a proxies.
  • Fix decoding responses with multiple zstd frames.
  • Fix RequestBuilder::form() from overwriting a previously set Content-Type header, like the other builder methods.
  • Fix cloning of request timeout in blocking::Request.
  • Fix http3 synchronization of connection creation, reducing unneccesary extra connections.
  • Fix Windows system proxy to use ProxyOverride as a NO_PROXY value.
  • Fix blocking read to correctly reserve and zero read buffer.
  • (wasm) Add support for request timeouts.
  • (wasm) Fix Error::is_timeout() to return true when from a request timeout.

v0.12.12

  • (wasm) Fix compilation by not compiler tokio/time on WASM.

v0.12.11

  • Fix decompression returning an error when HTTP/2 ends with an empty data frame.

v0.12.10

  • Add ClientBuilder::connector_layer() to allow customizing the connector stack.
  • Add ClientBuilder::http2_max_header_list_size() option.
  • Fix propagating body size hint (content-length) information when wrapping bodies.
  • Fix decompression of chunked bodies so the connections can be reused more often.

v0.12.9

  • Add tls::CertificateRevocationLists support.
  • Add crate features to enable webpki roots without selecting a rustls provider.
  • Fix connection_verbose() to output read logs.
  • Fix multipart::Part::file() to automatically include content-length.
  • Fix proxy to internally no longer cache system proxy settings.

v0.12.8

  • Add support for SOCKS4 proxies.
  • Add multipart::Form::file() method for adding files easily.
  • Add Body::wrap() to wrap any http_body::Body type.
  • Fix the pool configuration to use a timer to remove expired connections.

v0.12.7

  • Revert adding impl Service<http::Request<_>> for Client.

v0.12.6

  • Add support for danger_accept_invalid_hostnames for rustls.
  • Add impl Service<http::Request<Body>> for Client and &'_ Client.
  • Add support for !Sync bodies in Body::wrap_stream().
  • Enable happy eyeballs when hickory-dns is used.
  • Fix Proxy so that HTTP(S)_PROXY values take precedence over ALL_PROXY.
  • Fix blocking::RequestBuilder::header() from unsetting sensitive on passed header values.

v0.12.5

  • Add blocking::ClientBuilder::dns_resolver() method to change DNS resolver in blocking client.
  • Add http3 feature back, still requiring reqwest_unstable.
  • Add rustls-tls-no-provider Cargo feature to use rustls without a crypto provider.
  • Fix Accept-Encoding header combinations.
  • Fix http3 resolving IPv6 addresses.
  • Internal: upgrade to rustls 0.23.

v0.12.4

  • Add zstd support, enabled with zstd Cargo feature.
  • Add ClientBuilder::read_timeout(Duration), which applies the duration for each read operation. The timeout resets after a successful read.

v0.12.3

  • Add FromStr for dns::Name.
  • Add ClientBuilder::built_in_webpki_certs(bool) to enable them separately.
  • Add ClientBuilder::built_in_native_certs(bool) to enable them separately.
  • Fix sending content-length: 0 for GET requests.
  • Fix response body content_length() to return value when timeout is configured.
  • Fix ClientBuilder::resolve() to use lowercase domain names.

v0.12.2

  • Fix missing ALPN when connecting to socks5 proxy with rustls.
  • Fix TLS version limits with rustls.
  • Fix not detected ALPN h2 from server with native-tls.

v0.12.1

  • Fix ClientBuilder::interface() when no TLS is enabled.
  • Fix TlsInfo::peer_certificate() being truncated with rustls.
  • Fix panic if http2 feature disabled but TLS negotiated h2 in ALPN.
  • Fix Display for Error to not include its source error.
specta-rs/specta (specta)

v2.0.0-rc.24

Compare Source

This release is packed with fixes and cleanup from the last release.

A huge thanks to Flight Science's for funding me to be able do this work and complete the Specta 2.0.0 vision. A huge debt of gratitude is owed to them for making this all possible!

Changes:

  • Upgrade dependencies
  • Fixed stack overflow when serde_json::Value was exported
  • Removed specta::internal::construct in favor of public builder APIs
Stricter enums

Specta's Typescript exporter has historically been too permissive for certain enum shapes. Due to the way Typescript merges the type definitions it has be possible to construct multiple variants of a Rust type at once which is invalid. For example given the following type:

#[derive(Serialize, Deserialize, Type)]
#[serde(untagged)]
enum Example {
    A { a: String },
    B { b: String },
}

The following shows the difference between the old and the new rendered type:

// Specta's previous output. Notice we can parse both `a` and `b` which is incorrect.
type Example = { a: string } | { b: string };
const _: Example = { a: "aaaa", b: "bbbb" };

// Specta's new output
type Example2 = ({ a: string }) & { b?: never } | ({ b: string }) & { a?: never };

// This yields a Typescript error as expected:
const __: Example2 = { a: "aaaa", b: "bbbb" };

Checkout this Typescript playground if you want a better a better idea of the new exporters behavior.

Drop BigIntExportBehavior from Typescript exporter

The global BigIntExportBehavior configures how large integer types are exported, as by default they will be truncated by JS when deserializing. Although this global option is convenient, it's basically always a footgun to use so in the next release it's finally going to be removed.

We are working on official support for BigInt's in Tauri Specta and TauRPC so the need for a global option will no longer be required as these frameworks will make the error impossible. Until that is working these frameworks have a patch to ensure this won't cause issues for you!

For people not using a framework, this change will likely be very annoying as it will require overriding every single bigint-style field with an override annotation. Although this will be annoying it's much more technically correct and safer as it will ensure the developer writting the type is aware of the danger which BigIntExportBehavior previously allowed to be hidden away.

The Typescript exporter will always error (as if the legacy BigIntExportBehavior::Fail behavior) and it will have no overridable option to disable that. We will recommend overriding on a per-field basis but the developer could also generate a transformation function for the DataType structure (as this is what frameworks like Tauri Specta and TauRPC will do to surpress the error).

Below is our updated error documentation which gives guidance on how to deal with these issues:

[!TIP]

what to do about bigint errors?

Specta Typescript intentionally forbids exporting BigInt-style Rust integer types.
This includes [usize], [isize], [i64], [u64], [u128], [i128] and [f128].

This guard exists because JSON.parse will truncate large integers to fit into a JavaScript number type so we explicitly forbid exporting them.

If you encounter this error, there are a few common migration paths (in order of preference):

  1. Use a smaller integer types (any of u8/i8/u16/i16/u32/i32/f64).
    • Only possible when the biggest integer you need to represent is small enough to be represented by a number in JS.
    • This approach forces your application code to handle overflow/underflow values explicitly
    • Downside is that it can introduce annoying glue code and doesn't actually work if your need large values.
  2. Serialize the value as a string
    • This can be done using #[specta(type = String)] combined with a Serde #[serde(with = "...")] attribute.
    • Downside is that it can introduce annoying glue code, both on in Rust and in JS as you will need to turn it back into a new BigInt(myString) in JS.
  3. Use a Specta-based framework
    • Frameworks like Tauri Specta and TauRPC take care of this for you.
    • They use special internals to preserve the values and make use of specta-tags for generating glue-code automatically.
  4. UNSAFE: Accept precision loss
    • Accept that large numbers may be deserialized differently and use #[specta(type = f64)] to bypass this warning on a per-field basis.
    • This can't be set globally as it is designed intentionally to introduce friction, as you are accepting the risk of data loss which is not okay.

Everything is a NamedDataType

A major change in this Specta release is that all non-primitive Rust types are represented as a NamedDataType. This means they will be collected into the Types map, and can be specifically detected in exporter.

So Vec<T> is a named Vec type which resolves to a [T] which is just a DataType::List,
So String is a named String type which resolves to a str which is just a DataType::Primitives(Primitives::str),
etc.

From an end-user perspective nothing will change as the Typescript exporter is able to resolve and flatten these references automatically but if your crawling or mutating the DataType structure this may cause issues.

This change enables us to introduce a new impl Type for Result<T, E> implementation. This aligns us with Serde's behavior as they impl<...> Serialize for Result<T, E>.

We needed to make all of the types named so Specta-based frameworks like Tauri Specta can detect and split a std::result::Result into it's Ok and Err variants. This is required for properly implementing features like type-safe error handling.

This detailed type information could also be used in the future to inform the specta-rust exporter of the correct type to export, as without these named types all we have is the primitive represents which merges similar types for example Vec, arrayvec::ArrayVec, etc types become DataType::List and all maps like HashMap, BTreeMap, etc all become DataType::Map.

Tauri Specta phase-specific handling

We we launching support for phase-specific types into Tauri Specta to try out the new Specta APIs. The low-level APIs exposed from Specta are still experimental and may still undergo changes but they are now ready for usage to gather feedback!

This enables types like this to be defined in Rust:

#[derive(Serialize, Deserialize, Type)]
struct PhaseSpecificRename {
    #[serde(rename(serialize = "serialized_value", deserialize = "deserialized_value"))]
    value: String,
}

// This is a Tauri Specta command.
// Tauri Specta uses `specta_serde::apply_phases` to enable this behavior.

#[tauri::command]
#[specta::specta]
fn phase_specific_rename(input: PhaseSpecificRename) -> PhaseSpecificRename {
    input
}

This results in the following in the bindings.ts file:

// ...

export type PhaseSpecificRename = PhaseSpecificRename_Serialize | PhaseSpecificRename_Deserialize;

export type PhaseSpecificRename_Deserialize = {
	deserialized_value: string,
};

export type PhaseSpecificRename_Serialize = {
	serialized_value: string,
};

// ...

export const commands = {
    // Notice how we specialise the types for the usage!
	phaseSpecificRename: (input: PhaseSpecificRename_Deserialize) => __TAURI_INVOKE<PhaseSpecificRename_Serialize>("phase_specific_rename", { input }),
};

This will result in much more accurate types as we can react to the context (Serialize or Deserialize) to generate a better type. This will launch in the next Tauri Specta release which will hopefully come in the next week or so. TauRPC support is also coming soon with a PR right now in review...

Other

We have introduced the new specta-tags crate to enable #​203 but it's still very experimental. Stay tuned for more updates on it in the next release!

New Contributors

Full Changelog: specta-rs/specta@v2.0.0-rc.23...v2.0.0-rc.24

v2.0.0-rc.23: - Pouring the Foundation of 2.0.0

Compare Source

After a lot of anticipation, Specta is back with a major update that overhauls the core to prepare the project for the upcoming 2.0.0 release. While this release includes a number of new features, much of the work has focused on building the foundations for some exciting new capabilities that will be arriving in the near future.

Work on this release started in January 2025 and was put on hold multiple times, but thanks to Flight Science's funding I have been able to dedicate time to finishing the Specta vision and getting us much closer to a stable 2.0.0 release at last. A huge debt of gratitude is owed to them for making this all possible!

Multi-file and namespace exporting for TypeScript

We have added support for the highly requested feature which allows you to export your types into TypeScript namespaces, or multiple files instead of just outputting a single flat file of types. This is incredibly useful as your project scales and your single types file starts to become out of control.

Specta's new Typescript API takes care of all the complexity for implementing the different export flows. With the Typescript API you no longer need to use the low-level primitives for generating files, worry about filesystem operations, cross-file imports, deleting no longer required type files, checking for duplicate exports in a single scope, and more. We recommend migrating all applications and frameworks built on Specta to this API but the older low-level APIs still exist in specta_typescript::primitives.

You can check out the Typescript::layout method which is used to configure this new feature!

TypeScript branded types

This release introduces experimental support for branded Typescript types to be generated from Rust.

This means you can define Rust newtypes that are exported as branded TypeScript primitives, making it possible to model values like AccountId, UserId, and similar domain-specific strings more safely in the generated bindings. We also support integrations with any Typescript branded string library, including having examples for ts-brand and EffectTS's branded strings.

The exact API may change slightly for the final 2.0.0 release but you can check out how to define branded types with branded! and how to configure integration with third-party branding libraries via Typescript::branded_type_impl.

Your feedback on this feature would be welcome! Jump in the Discord!

Rename export feature to collect

This release renames the export feature to collect. The previous name could easily be confused with exporting types when this feature actually automatically collects types with the #[derive(Type)] macro so you can get a TypeCollection containing all your types for exporting them without manually registering each type.

This feature works identically to how it previously did. This change is just to reduce confusion and make documentation easier for the feature.

This rename touches feature flags, functions, and related attribute names. If you were previously using export, the migration is the following:

  • specta::export -> specta::collect
  • export feature -> collect feature
  • #[specta(export = false)] -> #[specta(collect = false)]

Removal of the TypeScript formatter integrations

Previously Specta TypeScript had the ability to integrate with Prettier, Biome, and other custom TypeScript formatters. I decided to remove support for this as I found that in the complexity of real-world projects with different package managers, monorepo configurations, and more, the feature would rarely work well out of the box and you would end up with your own custom implementation. This was no better than just leaving the implementation up to the end-user from the get-go.

We recommend you simply using std::process::Command to spawn your formatter's CLI as a subprocess after Specta's type exporting completes.

We have also made improvements to Specta's type formatting by default so another option is to just ignore the Specta generated bindings from requiring formatting.

std feature

Specta now has a std feature, enabled by default, which makes the standard library boundary much clearer. This follows the same pattern as the feature in Serde.

Without this feature enabled, the Type implementations won't be included for std::* types, so you may need to enable it if you use default-features = false in your Cargo.toml.

Format support

Specta's core is now much more format-agnostic than before.

Previously, a lot of Serde-specific behavior was effectively baked into the derive macro. In this release, raw attributes are lowered into runtime metadata and the actual Serde interpretation lives in the new specta-serde crate so it's completly decoupled from the specta and specta-macros crates. That means Specta's core can be used with other serialization libraries than Serde and can support any data-formats.

This is an important architectural change because it opens the door for other data formats to build on the same powerful type exporting information Specta has without being forced through Serde-specific assumptions. It makes Specta more of a general purpose type-introspection library.

This work also benifits Specta users which stick with Serde (as I suspect most people will) because it also lays the groundwork for us to be able to do phase-aware handling of types in the future. This feature would allow us to export your types with the phase (serialization or deserialization) metadata attached so frameworks like Tauri Specta, TauRPC, or rspc can accept narrower types than the current types which have to be a union between both types. For example #[serde(default)] could make a field optional when passed to a Tauri Specta command but it would be required on the response from a Tauri Specta command.

This change also necessitated a cleanup of the way attributes are handled in the Type derive macro. We have removed support for many #[specta(...)] attributes as you are now required to use #[serde(...)]. The #[serde(...)] attributes apply to both the types and runtime serialization/deserialization behavior while #[specta(...)] only applies to the types, so this change helps highlight code which is generally incorrect at compile time.

Reference overhaul

[!TIP]
A reference is used in Specta's type representation to show the value of a type refers to another one. For example if we produce type A = B<number>; the B<number> comes from a Reference.

A major change in this release is a deep overhaul of how Specta represents references internally.

The old SpectaID-based model worked really well for the #[derive(Type)] macro but it made it virtually impossible for your code to generate a type using a programmatic API at runtime. This use case is really useful for frameworks like Tauri Specta/rspc and also if you want to generate types from schemas or other runtime metadata.

Specta now also has stricter semantics around the usage of references. We have removed any public API for deleting references from the TypeCollection, making it much harder for errors to occur in the language exporters. With this change we have also split references into two types.

A named reference is just what we had in the old system. It's a reference to a NamedDataType, which is anything with #[derive(Type)] (or a runtime type built with (NamedDataTypeBuilder::build](https://docs.rs/specta/2.0.0-rc.23/specta/datatype/struct.NamedDataTypeBuilder.html#method.build)).

We have introduced a new kind of reference called an opaque reference. These have no semantic meaning to Specta's core but allow a language exporter like TypeScript to define custom behaviour when they are encountered. They are also configured to error by default if the exporter doesn't handle them. This means if you try and use a specta_typescript::Any with the specta-swift exporter your going to recieve a useful error now. This feature powers specta_typescript::{Any, Never, Unknown} and also branded types and specta_typescript::define, which allows injecting raw TypeScript code into your datatype structures.

Inline in the language exporter

[!TIP]
#[specta(inline)] is like #[serde(flatten)] at a type level. It allows the type's content to be inlined into the parent type's definition. As an end user you won't generally need this but its semantics are important to the reliability of the type export process.

One major internal shift in this release is that more of Specta's type processing now happens in the language exporter rather than in the macro expansion within the Type trait. In practice, this makes inlining much more reliable and much easier to reason about. It also prevents unsolvable stack overflows which can sometimes happen from recursive types.

With these changes the resulting fn definition implementation within the Type trait will contain DataType::Reference's to other types instead of calling <T as Type>::definition to get the DataType. This means we can't end up with infinite recursion when calling definition on a recursive type. This is really important for the collect feature as stack overflows in ctor can cause full-program crashes. The references now also contain information about whether they should be inlined which is then picked up by the language exporter (TypeScript) which is able to flatten the type definition properly.

These changes also enabled inlining to now behaves as you would expect through wrappers like Option<T> and Box<T> where it now inlines T. Older versions of Specta would apply the inline to Option<T> instead of peeking through the containiner and inlining T, which meant #[specta(inline)] Option<T> actually didn't change from a regular Option<T>.

This work also improved how Specta decides whether a type actually needs to be emitted as a referenceable export. Types that can only ever be inlined (Eg. #[specta(inline)] on the container) no longer produce pointless named exports in the resulting bindings file.

For downstream frameworks like Tauri Specta and TauRPC, this release also improves the TypeScript exporting pipeline so that frameworks can include their own runtime TypeScript code via Exporter::framework_runtime while allows them to take advantage of Specta's new multi-file exporting without needing to reimplement all of it's logic into their own crate. This also reduce the amount of filesystem and type wrangling code frameworks need to maintain and allows the ecosystem to work on a single battle tested implementation of the logic.

Published new language exporter crates

We have published all of the crates in the Specta monorepo to crates.io. These include some beta and some unfinished language exporter crates. Most of them are not ready for prime time at the moment, but hopefully work on them can begin soon.

Swift should be usable and Go is coming in the next release thanks to the work of @​philocalyst in #​448. If your use case requires one feel free to reach out or open a PR!

For the foreseeable future the Typescript exporter is the recommended language exporter as it receives the majority of the development effort. If your want to sponsor work on or maintain a specific language exporter I would love to hear from you!

Breaking changes

As expected for a release with this much stuff it includes a number of breaking changes, especially for advanced users, framework authors, and anyone using low-level Specta APIs directly. Most end-users won't see as much of an impact.

Some changes include:

  • export has been renamed to collect, including feature flags and related APIs.
  • SpectaID has been removed from the public model.
  • NamedType, Flatten, and Language have been removed from core.
  • DataType::Any, DataType::Unknown, and DataType::Literal have been removed.
  • Older public datatype items such as EnumVariants, StructFields, LiteralType, PrimitiveType, GenericType, EnumType, StructType, TupleType, DataTypeReference, and reference::Reference were removed or reworked.
  • Type::inline and Type::reference were removed from the Type trait in favor of the newer definition/reference model.
  • TypeCollection changed significantly, including the removal of methods like insert, extend, remove, and get, and register now takes ownership of Self instead of &mut Self.
  • The export, serde, and interop features were removed from specta.
  • specta-jsdoc has been folded into specta-typescript as specta_typescript::JSDoc.
  • specta-rust has been removed for now.
  • specta::json has been removed.
  • Serde-style behavior is no longer accepted through deprecated #[specta(...)] forms; Serde attributes now belong to Serde and are handled through specta-serde.
  • specta-typescript had its API restructured heavily: the old root-level export, export_ref, inline, inline_ref, export_named_datatype, and datatype helpers are gone in favor of Typescript, JSDoc, Exporter, and primitives::* APIs.
  • specta_typescript::ExportError and related types were removed in favor of the newer sealed specta_typescript::Error model.
  • The function feature was removed from specta-typescript.

If you see any issues upgrading jump in the Discord and we can help you out!

What's next?

Much of the work in this release is foundational work for the next stage of Specta.

We can now start working on:

  • handling for special datatypes like BigInt, Date, UInt8Array, etc.
  • handling types differently across each phase (serialization vs deserialization) with Serde
  • stronger support for Serde attributes (we don't implement a handful of them yet)
  • reliability (you can never have enough tests!)
  • and lots more!

This release is a major milestone in the path towards the stable release Specta v2. We are now in a place where I can see the final release is in sight which is very exciting.

New Contributors

A huge thanks to all the people who contributed to this release!

Full Changelog: specta-rs/specta@v2.0.0-rc.22...v2.0.0-rc.23

tauri-apps/plugins-workspace (tauri-plugin-single-instance)

v2.4.1

specta-rs/tauri-specta (tauri-specta)

v2.0.0-rc.24: - Phasing Forward

Compare Source

A huge thanks to Flight Science's for funding me to be able do this work and complete the Specta 2.0.0 vision. A huge debt of gratitude is owed to them for making this all possible!

Upgrade Specta

Upgrade Specta to the latest version!

Ensure you update your dependencies to be the following:

tauri-specta = "=2.0.0-rc.24"
specta = "=2.0.0-rc.24"
specta-typescript = "=0.0.11"

Checkout the v2.0.0-rc.24 and v2.0.0-rc.23 release notes for breaking changes.

Phase-specific types

We we launching support for phase-specific types into Tauri Specta to try out the new Specta APIs. The low-level APIs exposed from Specta are still experimental and may still undergo changes but they are now ready for usage to gather feedback!

This enables types like this to be defined in Rust:

#[derive(Serialize, Deserialize, Type)]
struct PhaseSpecificRename {
    #[serde(rename(serialize = "serialized_value", deserialize = "deserialized_value"))]
    value: String,
}

// This is a Tauri Specta command.
// Tauri Specta uses `specta_serde::apply_phases` to enable this behavior.

#[tauri::command]
#[specta::specta]
fn phase_specific_rename(input: PhaseSpecificRename) -> PhaseSpecificRename {
    input
}

This results in the following in the bindings.ts file:

// ...

export type PhaseSpecificRename = PhaseSpecificRename_Serialize | PhaseSpecificRename_Deserialize;

export type PhaseSpecificRename_Deserialize = {
	deserialized_value: string,
};

export type PhaseSpecificRename_Serialize = {
	serialized_value: string,
};

// ...

export const commands = {
    // Notice how we specialise the types for the usage!
	phaseSpecificRename: (input: PhaseSpecificRename_Deserialize) => __TAURI_INVOKE<PhaseSpecificRename_Serialize>("phase_specific_rename", { input }),
};

This will result in much more accurate types as we can react to the context (Serialize or Deserialize) to generate a better type. We would love you to open issues with feedback as this is a fairly new feature!

You can disable it by using Builder::disable_serde_phases if you would like to restore the previous behavior.

Other

New Contributors

Full Changelog: specta-rs/tauri-specta@v2.0.0-rc.21...v2.0.0-rc.24


Configuration

📅 Schedule: (in timezone Asia/Tokyo)

  • Branch creation
    • "at 19:00 on Friday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot added the dependencies label Jan 4, 2026
@renovate renovate bot force-pushed the renovate/backend-update-dependencies branch 4 times, most recently from f903319 to 99898d2 Compare January 11, 2026 16:55
@renovate renovate bot force-pushed the renovate/backend-update-dependencies branch 2 times, most recently from 8735e82 to 464e254 Compare January 21, 2026 18:25
@renovate renovate bot force-pushed the renovate/backend-update-dependencies branch 2 times, most recently from 7352db2 to 343ad4b Compare February 2, 2026 21:40
@renovate renovate bot force-pushed the renovate/backend-update-dependencies branch 6 times, most recently from 03b47f9 to ce02647 Compare February 10, 2026 16:07
@renovate renovate bot force-pushed the renovate/backend-update-dependencies branch from ce02647 to 1c46694 Compare February 12, 2026 14:37
@renovate renovate bot changed the title chore(deps): lock file maintenance [backend] update dependencies chore(deps): update [backend] update dependencies Feb 12, 2026
@renovate renovate bot force-pushed the renovate/backend-update-dependencies branch 2 times, most recently from 101e4be to f556198 Compare February 26, 2026 13:51
@renovate renovate bot force-pushed the renovate/backend-update-dependencies branch from f556198 to 6443770 Compare March 5, 2026 19:59
@renovate renovate bot force-pushed the renovate/backend-update-dependencies branch 4 times, most recently from b0205ea to b254c4d Compare April 7, 2026 17:49
@renovate renovate bot force-pushed the renovate/backend-update-dependencies branch 2 times, most recently from ae24b7d to be8e4f3 Compare April 17, 2026 15:41
@renovate
Copy link
Copy Markdown
Contributor Author

renovate bot commented Apr 17, 2026

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: src-backend/Cargo.lock
Command failed: cargo update --config net.git-fetch-with-cli=true --manifest-path src-backend/Cargo.toml --package tauri-plugin-single-instance@2.4.0 --precise 2.4.1
    Updating crates.io index
error: failed to select a version for the requirement `tauri-plugin-deep-link = "^2.4.8"`
  version 2.4.8 is yanked
location searched: crates.io index
required by package `tauri-plugin-single-instance v2.4.1`
    ... which satisfies dependency `tauri-plugin-single-instance = "^2.3.2"` of package `konoasset v1.2.6-rc.3 (/tmp/renovate/repos/github/siloneco/KonoAsset/src-backend/tauri)`

@renovate renovate bot force-pushed the renovate/backend-update-dependencies branch from be8e4f3 to 05b6191 Compare April 18, 2026 07:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant