json-schema-to-typescript VS nestjs-openapi3

Compile JSONSchema to TypeScript type declarations

Nice! Lots of tricky edge cases to do this right: there’s ambiguity in the JSON Schema spec, version-to-version changes, many popular community conventions that don’t adhere to the spec, etc. Feel free to check out the tests to understand some of these: https://github.com/bcherny/json-schema-to-typescript (shameless plug — I have maintained this library for a number of years).

jsonnet is my go-to language for anything related to configuration, after having tried json, yaml, TS, edn, and tasting dhall and toml. It addresses all problems in the article and more.

the composition strikes a good balance between extensiveness and ease of use.

the generated json leads to easy and portable data, and if you write jsonschemas from jsonnet, tools like json-schema-to-typescript [1] make it easy to import a consistent interface, and almost every language has a reasonably up-to-date validation library.

[1] https://github.com/bcherny/json-schema-to-typescript

Take a look at https://github.com/bcherny/json-schema-to-typescript, too. I used it successfully at a previous job. IIRC, I had to write some code to convert OpenAPI to JSON Schema but it wasn’t onerous

If you're using OpenAPI, you could use this to generate TypeScript interfaces:

https://github.com/bcherny/json-schema-to-typescript

It works really well

I'm messing around with a process to convert JSON schemas to TypeScript interfaces using json-schema-to-typescript. I have a little under 900 JSON files each containing a schema, totaling about 3.5 MB.

json-schema-to-typescript

So I spent a lot of time in the Nest ecosystem, and I wrote some nontrivial libraries with a little (not a lot) of uptake (and neither are actively maintained at this point, so these are here mostly for completeness):

https://github.com/eropple/nestjs-auth

https://github.com/eropple/nestjs-openapi3

I was pretty excited by NestJS when I ran into it because, well--I don't mind magic, when it's done right. I quite like Spring Boot, for example. But NestJS's magic is...incorrect, in a lot of ways. The DI container is a little bit scary, with oddly hardcoded ways to register interceptors into request scope (itself necessary because NestJS's logging facilities aren't--or weren't at the time--decorating requests with X-Request-Id or similar, so you had to register your own) and no way to then define interceptor order.

It also has a lot of really overlapping nouns; guards are interceptors but less capable (and @eropple/nestjs-auth didn't use them at all) and the "pipe" concept for validation was itself inscrutable. To make it usable, I ended up just doing everything with decorators and interceptors, all living in request scope. And once I'd gotten it going, it was pretty nice. But it also meant broad incompatibilities with much of the NestJS ecosystem.