Oscar Beaumont

`specta-impls` crate

3

This code is cursed but I think it's the way. I want Specta v2 to be able to develop an ecosystem. That means independent crates implementing `specta::Type` instead of it...

Pull this from Mattrax into the main repo. https://github.com/mattrax/Mattrax/tree/main/crates/specta-zod

You should be able to export a TS type without the Serde checking, like how we allow BigInt's to be configurable.

Remove all `use ::*`

1

It's both bad for semver and also can cause unintended LSP hints. Right now Rust Analyser wants to import `FunctionDataType` from `specta::js_doc::FunctionDataType` not `specta::functions::FunctionDataType`

What should be public or not? Should it's args be a sealed struct or not?

https://github.com/serde-rs/serde/pull/2641#pullrequestreview-1732728579 It's not too late to remove it.

Better `TypeId`

4

Hack around the `'static` bound on Rust's built-in `TypeId` to allow the ID to be tied to a compiler intrinsic instead of the implementation location of the macro like it...

Even better DataType system

1

- Can we rethinking `DataTypeFrom`. It should work with it's own SpectaID so `NamedDataTypeExt` could be required. - `DataTypeFrom` should always use `DataType::Map` not `DataType::Struct`??? - Can this work. `TupleType`...