I wonder if something like:

#[derive(Type)]
pub struct A {
   a: String
}
#[derive(Type)]
pub struct B {
   #[specta(inline)]
   b: Option<B>
}

should be export A = { b: { a: String } | null } instead of export A = { b: B | null }.

This would require a refactoring of the generic handling because currently the B comes from generics and is always a reference.

It would also be nice to add #[specta(inline_all)] which would opts.any_parent_inlined ? Type::inline : Type::reference for generics. This way.

Redo handling of opts. parent_inline. We should (in most cases) not pass opts directly to child impls because parent_inline is only valid for the type above the current one.

Which exports as a Date in TS.

oscartbeaumont/rspc#40

• Go language support
  • Exporting primitive types
  • Exporting doc comments
  • Export deprecated param from Rust
  • Types that work with serialization/deserialization
  • Fully tested
  • Unit tests using the child language compiler to double-check for valid syntax

Specta's Type macro and it's vast number of implementations add code to the build process and the final bundle being shipped to your clients. These types serve no purpose in production builds because you export the types using a development build. It would be nice if they could be removed from the build (without relying on LTO because that increases build time and may not be perfect). I propose:

We introduce a trait as follows:

pub trait TypeMarker {}

Then we modify Type so:

pub trait Type: TypeMarker { ... }

Then we modify the RSPCType macro so that it removes the Type trait implementation for release builds.

Finally rspc can be upgraded to only require TypeMarker at runtime but still have the guarantee that the type supports exporting (unless it were to panic during exporting and I think that's a risk we can live with). This should be configurable on rspc and Specta so that you can force it to include the type information if you really want to do type exporting at runtime.

Specta already has a prototype of this but more work needs to be done before it can used.

Blocking issues:

• How to handle generics?

I'm using specta in a context in which there are many potential collisions with the list of reserved TS words, as defined here. I'm filing this because, to the best of my knowledge, neither object keys nor string union types need to avoid these keywords. For context, I'm generating these types with the specta::export::ts_with_cfg method.

Needed to change key "from" to "nodeFrom" to get successful compilation due to reserved keyword "from".

Needed to change string "default" to "defaultMode" to get successful compilation due to reserved keyword "default".

https://github.com/1Password/typeshare

• #18

Should be able to replace schemars

• Swift language support
  • Exporting primitive types
  • Exporting doc comments
  • Export deprecated param from Rust
  • Types that work with serialization/deserialization
  • Fully tested
  • Unit tests using the child language compiler to double-check for valid syntax

• Rust unit tests
• Throw a bunch of types into a file and run them through the languages compiler so we can be certain it's valid syntax in the latest release

Currently, methods like Type::inline take &[DataType]. This means you can pass an incorrect number of generics. We have a runtime fallback in case of a mistake but it would be nice to just not allow it to be wrong. Given these methods are an implementation detail is not the end of the world but it would be an extra protection against bugs.

Can probs be fixed by something like:

pub trait Type {
    const GENERICS: usize = 2;

    fn inline(..., generics: [DataType; 2]);
}

Eg.

struct Demo<const U: usize> {

}

fn demo<const I: usize>() {

}

This would allow cleaning up the impls.ts file a heap without negatively effecting compile time for crates using Specta.

Currently, Specta will panic if it encounters a bigint. This is because when using Typescript exporting with JSON and using JSON.parse (like Tauri and rspc use) will cause the number to be incorrect decoded on the frontend. Specta should support bigint because it's transport dependant but it should allow disabling bigint types.

So assert_eq!(..., Err(...)); works with Specta errors. This really annoying but io::Error doesn't impl PartialEq so will need to work around that by converting it into a custom Specta type.

• Rust language support
  • Exporting primitive types
  • Exporting doc comments
  • Export deprecated param from Rust
  • Types that work with serialization/deserialization
  • Fully tested
  • Unit tests using the child language compiler to double-check for valid syntax

WIT

Allow modifying the export behavior on a per-type basis and add in all other number types likeu32.

Allow setting a different error message on a per-type basis.

Why? serde_json supports u64 but not u128 by default but Specta treats them the same. This is mostly a feature for library authors but is good to have.

rspc would disable u128 unless Speca (and Serde's) arbitrary-precision feature is enabled. If arbitrary-precision is enabled we should probs change all number types to strings. Idk check that with Serde's docs.

Eg.

pub struct Demo<T = String> {

}

It would be super nice if Specta could work on no_std or at least not allocate memory given all of the structures implemented in the macro are fixed at runtime. The main require change here will be using static slices instead of vectors.

Using references will probably allow removing a lot of the cloning from the Typescript exporter.

None of this should come at the cost of DX, it's a micro-optimization.

const _: () = {
      const TY: ObjectType = ...;

       // Then use something like this in the `Type` impl.
       // fn type() -> &'static ObjectField { &TY }
};

oscartbeaumont/rspc#83

oscartbeaumont/rspc#100

Right now to export a function all arguments must implement serde::Serialize and all results must implement serde::Deserialize. Can we make it so this bound isn't required but without breaking tauri-specta.

For most cases this will be fine because serde can be used in the transport layer but if you wanna do FFI or use a non-serde compatible encoding you will currently have a bad time.

Development:

• Export comments from Rust
• automatically_derived on proc macros output
• tokio::sync::* types added to Specta
• #7
• #19
• #9
• #11
• #10
• #12

Release:

• Merge specta from rspc back into specta
• Make Specta repo public
• Corresponding rspc release
• Corresponding PCR release

#[derive(Type)]
pub struct MyType {
      #[specta(inline)] // This is the bug
      me: Box<MyType>,
}

This will probs stack overflow and we should detect and prevent it before that stage.

Idk what the current behavior is but it should probs be an easy-to-understand error because I don't think it's possible to support this.

Export subset of types to individual files. Eg.

#[derive(Type)]
#[specta(export  = "api")]
pub struct TypeOne {}

#[derive(Type)]
#[specta(export  = "api")]
pub struct TypeTwo {
     A(TypeTwo), // In the bindings we will need to `import { TypeTwo } from "/microservice.types.ts";` or fail if the user doesn't export `microservice` types.
}

#[derive(Type)]
#[specta(export  = "microservice")]
pub struct TypeTwo {}

// Then when using Specta's export feature you will do something like
export(&[("api", "./api.types.ts"), ("microservice", "./microservice.types.ts")], &[Alias::for::<T>("api")])); // You can omit a context to not export it. Use `Alias` to set the ctx of an external type.

One from crate::export and one from crate::ts::export. This is annoying with IDE autoimport and kinda confusing for a developer.

Cause we are sure missing a few of them.

I am trying to use this crate along with the tauri-specta crate to build an app that is attached to an SQLite database. I am using sea_orm as my ORM and it has an interesting quirk where every model struct must be named Model. For example:

#[derive(Debug, Clone, PartialEq, DeriveEntityModel, Serialize, Deserialize, Type)]
#[sea_orm(table_name = "tests")]
#[serde(rename_all = "camelCase")]
pub struct Model {
    #[sea_orm(primary_key)]
    #[serde(skip_deserializing)]
    pub id: i32,
    pub name: String,
    pub description: String,
}

This is resulting in type declarations that contain errors because the exported types have the same name. I am using this crate to replace a needlessly complicated type generation system using schemars::JsonSchema which allows me to use the attribute: #[schemars(title = "Test")] and the type declaration will have that name. It would make sense to add an attribute within this crate instead of going the route of parsing yet another crates macro attributes, especially if this would be the only attribute you'd borrow from schemars. I will see about implementing this myself and submitting a pull request, and I will update here if I feel it is beyond my capabilities to do so. Thank you :)

[dependencies]
serde = { version = "1", features = ["derive"] }
serde_json = "1"
specta = { version = "1", features = ["typescript"] }

use specta::{ts, Type};

#[derive(Type)]
#[derive(serde::Serialize)]
enum MyEnum {
    OneWord,
    #[serde(rename = "Two words")]
    TwoWords,
}

fn main() {
    println!("{}", serde_json::to_string(&MyEnum::OneWord).unwrap());
    println!("{}", serde_json::to_string(&MyEnum::TwoWords).unwrap());
    println!("{}", ts::export::<MyEnum>(&Default::default()).unwrap());
}

I got this:

"OneWord"
"Two words"
export type MyEnum = "OneWord" | ""Two words""

Instead it should be

export type MyEnum = "OneWord" | "Two words"

• #17
• #16
• #9

A common pattern I have seen in Spacedrive is:

#[cfg(feature = "specta")]
impl specta::Type for PeerId {
	const NAME: &'static str = "PeerId";

	fn inline(opts: specta::DefOpts, generics: &[specta::DataType]) -> specta::DataType {
		<String as specta::Type>::inline(opts, generics)
	}

	fn reference(opts: specta::DefOpts, generics: &[specta::DataType]) -> specta::DataType {
		<String as specta::Type>::reference(opts, generics)
	}

	fn definition(opts: specta::DefOpts) -> specta::DataType {
		<String as specta::Type>::definition(opts)
	}
}

This could easily be replaced by the macro making for better DX and also less pain when upgrading Specta.

ReScript

oscartbeaumont/rspc#26

Is it possible to validate enum tagging in the macro such that we don't need to a runtime error for it?

Having the error makes collate_types! cringe.

DataTypeExt makes handling exporting of ToDataType stuff complicated and idk how to make it work.

• Kotlin language support
  • Exporting primitive types
  • Exporting doc comments
  • Export deprecated param from Rust
  • Types that work with serialization/deserialization
  • Fully tested
  • Unit tests using the child language compiler to double-check for valid syntax

Currently, we just throw () inside the generics while exporting. This may not conform to the trait bounds defined by the user on the type. Work around this by requiring the user to specify the type to use either as a default generic or using a Specta derive macro attribute.

Also reenable test_generic_trait_bounds unit test.

The Specta macros are additive only with boolean args and they shouldn't be. Eg.

#[derive(Type)]
pub struct Demo {
    #[serde(flatten)]
    #[specta(flatten = false)]
    pub demo: SomeType, // We should not flatten this type because Specta takes preference and overrode Serde
}

#[derive(Type)]
#[specta(export = false)]
pub struct Demo2 {
    pub demo: SomeType,
}

• Custom error type
• Report name of field in form like object>field>field>field or object>variant>field so that it's easy to know where the error occurred.

Not working in the macro. Gonna have to open an issue in syn or Rust.

As a workaround you can use the doc comment exporting:

/// Some comments
///
/// @deprecated I hate this type
#[derive(Type)]
pub struct MyType(String);