@schema-ts

[jacob-alford]

This would be a target change for a 2.0.0 release.

@newswim mentioned the idea of turning schema-ts (or schemata-ts if it's tomorrow) into an organization/workspace. This is a thread for possible workspace hierarchies

[jacob-alford]

Here's a relevant message to @newswim:

That's a neat idea! I do like the idea of PatternBuilder getting its own repo. I think it adds a bit too much complexity for v1. And there's also some ambiguity about the direction of @fp-ts/codec.

So we might need to write our own Schemable if @fp-ts/codec changes the API. Then, a workspace would make much more sense. With two independent repos: @schema-ts/pattern-builder, @schema-ts/core; and three dependent repos: @schema-ts/schemata, @schema-ts/common-instances, and @schema-ts/arbitrary

[jacob-alford]

flowchart TD 
  core --> schemata
  pattern-builder --> schemata
  core --> common
  pattern-builder --> arbitrary

Loading

[newswim]

What were you thinking ought to go into common? My thought would be that maybe those can things could just go into core (and cut down on one additional package).

[jacob-alford]

I was thinking the decoder, encoder, etc instances. And core would just be the things in src/primitive

[skeate]

I personally think this is a bad idea. What is gained by fragmenting this?

core would just be the things in src/primitive

is "primitive" here referring to string/number(/date?)

Also I'm skeptical of the idea of breaking pattern-builder out to its own thing. The whole point of it is to serve as a generalization of the schemable additions we have. This means (1) all instances of Schemable need to understand far fewer things, and (2) they become far more flexible to accommodate novel structures.

What is the goal of the library? I'm biased, but I feel like PatternBuilder and other things in that vein -- providing new fundamental building blocks that consumers of the library can use to create more complex structures -- is more useful and more in line with the core idea of Schemable in the first place. Being able to provide schemata for extremely specific things like PositiveIntString or BitcoinAddress or whathaveyou is useful but secondary.

[jacob-alford]

Fair enough! I think there was two reasons for it (three sort of):

• Secure the schema-ts namespace, and match the style of @Effect-TS and @fp-ts
• reduce bundle size by moving arbitrary to its own package as an opt-in.

Ultimately I agree with you, that it's not worth all the trouble/complexity