Vision for json_schema_builder package? Want to generate schema from dart models?

[alexobviously]

Hey, excuse the "issue" that isn't an issue, but the discussions section of this repo isn't allowing me to create a discussion.

I just wanted to start a discussion here, because I'm also working on a json schema related tool - specifically, a way to generate schema files from dart models. I'm wondering if that seems like something that you'd think might align with this project you have here, and whether I should consider contributing to this instead?

I remember @sethladd asking here about this exact thing, and he seems to be around here too, so I guess this package might have come partly from that desire?

Anyway, if that's something on your roadmap/wishlist, I have some analyzer based code that's a bit rough but working, and I could probably port over to your models here and get a script together.

fwiw I am not building this for any reason related to LLMs (some kind of contract testing), but could imagine it being useful to you guys. I guess part of my question here is how tightly coupled do you think json_schema_builder is to the GenUI project? Like how specific to your use case do you see the package being going forward? Because this sort of thing is more generally useful than just some LLM component.

[alexobviously]

Maybe I should be clear about what I'm making just so you have context of what I'd be incorporating if I started doing it here instead: basically a script which goes through the codebase, finds classes annotated with @JsonSchema() and generates thing.schema.json files from them.

Right now I have it using build_runner, but I don't like the limitation of 1:1 source:generated files, because a) sometimes files contain multiple classes I want to generate from and b) I want to be more flexible with where the files generate (since I want to generate basically a whole schema folder that's a mirror of the source dir, rather than have them next to their respective source files like I have now). So I'm probably going to move away from build_runner (though maybe keep an integration with it) and just have an executable that you run like dart run json_schema_generator with some yaml config file.

I think for your use case you would probably want the build_runner version, but yeah probably pretty simple to organise the logic such that there's a central way to generate a schema from a class and it's easy-ish to support multiple execution methods (though I might anticipate some difficulties in $refs to other local classes).

[sethladd]

Hey, excuse the "issue" that isn't an issue, but the discussions section of this repo isn't allowing me to create a discussion.

interesting, sorry about that. I see the Discussion tab. What kind of error(s) do you get when trying to create a discussion?

[alexobviously]

Hey, excuse the "issue" that isn't an issue, but the discussions section of this repo isn't allowing me to create a discussion.

interesting, sorry about that. I see the Discussion tab. What kind of error(s) do you get when trying to create a discussion?

The new discussion button is just missing. If I remember correctly there's some permission setting somewhere like "people with read access can create discussions"

But also if you're an owner of this repo, there's a button at the bottom right of this issue that says "convert to discussion", so you can do that with this issue :)

[sethladd]

Thanks, I converted this to a discussion.

I might not have the permissions to enable "people with read access can create discussions", as I can't find that. But I'm looking around.

[sethladd]

A teammate just enabled folks with read access to create new discussions. Thanks for letting us know about that.

Now we can get back to your first question :)

[gspencergoog]

The vision for this package was to create something that made it easy to create concise schemas in Dart code (a la Zod for Node) without having to have dependencies on generated code, and which could do complete validation of JSON schemas.

The fact that wanting to do both of those things in the genui project motivated creating the package shouldn't stop this package from being entirely independent of the genui project: it's not at all tied to genui use cases or code: it's just concerned with creating and validating JSON schemas.

The "without using code generation" piece was important to me because code generation isn't transparent in Dart: you have to run some other command to do the generation. It adds annoying extra files that have to be regenerated when their source changes, they have to be checked for staleness in CI, and tracked in revision control. I had high hopes for the macros feature for Dart, but sadly that work was abandoned.

I know that code generation opens up a lot of possibilities, and it always has the promise of being easy to use and powerful, but in my experience it just makes things more complicated when you try to set up a build, or CI, or figure out what is actually happening when something goes wrong: generated code is rarely well documented, clearly written code. If I can do it in regular code, I'd rather do that. For instance, I'd rather maintain a fake for testing than use a generated mock.

So, while I welcome additions to the package, I think that maybe your goals for your package might be different than mine here.

But convince me! If you can show enough advantage to the approach, I can totally be convinced! I honestly would love if someone could solve the problems with generated code without losing the advantages, but I know that's a hard problem.