ts-lite
openapi-preprocessor
ts-lite | openapi-preprocessor | |
---|---|---|
1 | 2 | |
48 | 34 | |
- | - | |
0.0 | 3.7 | |
over 2 years ago | about 1 month ago | |
JavaScript | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ts-lite
-
Show HN: Monocle – bidirectional code generation library
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
openapi-preprocessor
-
Show HN: Monocle – bidirectional code generation library
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
-
JSON Schema bundling finally formalised
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.
What are some alternatives?
qwik - Instant-loading web apps, without effort
oasdiff - OpenAPI Diff and Breaking Changes
recast - JavaScript syntax tree transformer, nondestructive pretty-printer, and automatic source map generator
zod - TypeScript-first schema validation with static type inference
Monocle - Optics library for Scala
ajv - The fastest JSON schema Validator. Supports JSON Schema draft-04/06/07/2019-09/2020-12 and JSON Type Definition (RFC8927)
escodegen - ECMAScript code generator
api-firewall - Fast and light-weight API proxy firewall for request and response validation by OpenAPI specs.
Babel (Formerly 6to5) - 🐠 Babel is a compiler for writing next generation JavaScript.
io-ts - Runtime type system for IO decoding/encoding
apiclarity - An API security tool to capture and analyze API traffic, test API endpoints, reconstruct Open API specification, and identify API security risks.
gnostic - A compiler for APIs described by the OpenAPI Specification with plugins for code generation and other API support tasks.