Package restructure

[decs]

Hey, folks! I’ve been thinking of ways to scale TypeSchema to provide the features you’ve been asking about:

• Supporting more validation libs: We currently support 14 libs, but there’s always more. How can we grow the platform without increasing the bundle size to everyone?
• Functionality beyond validate/assert: toJSONSchema has been a longstanding ask (Beyond validation - introspecting the schema #9). How can we provide flexibility to gradually introduce new features?

I’ve reached the conclusion that the current architecture doesn’t really scale and a restructuring is due. My vision is to make TypeSchema fully flexible, while still being smart about bundle size. And we can’t get there without optional peer dependencies.

Optional peer dependencies is the single biggest feature that makes TypeSchema possible. They allow us to leverage other libs without making them a dependency for everyone, just for people who actually require that functionality. The not so good part is that bundlers sometimes don’t handle them well (#12, #24, #28). Though, I truly believe that continuing to address these issues one-by-one is feasible and it’ll make TypeSchema more stable long term.

I’ve been working on migrating the adapters to a new structure, to be released on v0.13.0 by the end of February. You can take a peek under the monorepo branch, but I’ll cover the key decisions here.

Multiple packages

I was lucky enough to get access to the @typeschema organization on npm, so this feels like a great opportunity to split TypeSchema into multiple packages:

• @typeschema/valibot, @typeschema/arktype, etc: Each validation lib will have their own independent package, containing all of its adapter code. Those packages will be self-sufficient and can be used directly. This will be particularly useful for those who use TypeSchema to pass a valibot schema to tRPC, for example.
• @typeschema/main: This will be the main entrypoint to TypeSchema. This package will take any schema, identify which adapter we should be using, and redirect the call to it.
• @typeschema/core: This package will contain all the common adapter code and will be a direct dependency for all others.

Dependencies

Being mindful of the bundle size means only including code that you’re actually going to use. That’s why @typeschema/main is going to work slightly different than usual. It will only contain the routing code, and all adapter packages will now be optional peer dependencies. This enables people to explicitly decide which validation libs they’d like to support, just by adding/removing adapter packages to their project. And this can be done on demand: whenever TypeSchema tries to use a dependency that’s not installed, you’ll get a runtime error letting you know which package to add.

The adapter packages themselves will also only contain optional peer dependencies. So it's always safe to install them, even if you don't have the underlying validation lib installed. This enables creating a @typeschema/all package that automatically includes all adapter packages as direct dependencies. This package will be a drop-in replacement to @decs/typeschema.

Code generation

Making these adapter packages standalone and tree-shakeable isn’t trivial in pure Typescript. So, to make the code more expressive and avoid manual repetition, we’ll leverage codegen. This will only affect TypeSchema developers and won’t change the experience for package users.

Ask

I wanted to make sure to share this plan with community members to get any feedback or suggestions you all may have.
cc @ecyrbe, @ssalbdivad, @ciscoheat, @thelinuxlich, @TheEdoRan, @juliusmarminge, @Talent30, @fabian-hiller

Looking forward to making this a reality. Thanks, all!

[fabian-hiller]

This sounds great to me. I look forward to hearing feedback from the tRPC core team. TypeSchema seems like a perfect fit for their use of schema libraries.

[Talent30]

cc @oliverbutler @franky47 @Gabrola @michaelangeloio You guys might be interested :)

[TheEdoRan]

This is great! Thank you for this update. Looking forward to use TypeSchema v0.13 in next-safe-action v7!

[decs]

@TheEdoRan v0.13.0 is live! exciting times for TypeSchema!

I'm curious on whether you prefer using @typeschema/main or @typeschema/all. feel free to reach out on X (@heydecs) if you'd like to chat about the tradeoffs