ts-lite VS openapi-preprocessor

This is neat! I’m curious if you see this being extended for other languages, or the concept being applied in other projects?

As for similar concepts, several projects by builder.io have some overlap. Most notably Mitosis[1], but I’d be shocked if TS-Lite[2] isn’t using similar techniques. Potentially Qwik[3] as well but I’m not sure, I would have bet that’s using Mitosis but it looks like that’s the other way around.

1: https://github.com/BuilderIO/mitosis

2: https://github.com/BuilderIO/ts-lite/tree/main/packages/core

3: https://github.com/BuilderIO/qwik

I use a mixed approach for OpenAPI, but not bidirectional.

I have OpenAPI pieces generated from my Go source code (comment, types, function signatures) as JSON.

I also have a manually-edited master YAML document that refers to generated bits via $ref links.

I then use openapi-preprocessor [1] (disclaimer: I wrote it) to produce a final openapi.json file which is committed in the repo.

When I want to extend the API in a spec-first process, I can add the new routes manually in the YAML file. When I do the implementation I replace the manual bits by the generated one when they are ready. When committing I can check the diff of openapi.json to verify I'm not losing in the process.

[1] https://github.com/dolmen-go/openapi-preprocessor

Bundling for OpenAPI specification has long been a need for authors to allow to reduce duplication, and to allow to split a big specification in multiples files, but publish a single one.

A few years ago I've written a tool to fit that niche: https://github.com/dolmen-go/openapi-preprocessor

https://github.com/dolmen-go/openapi-preprocessor

I have now to tweak it (well, it will be a major rewrite) to handle $ref relative to $id instead of the file location.