JSONSchema as a separate library #272
Replies: 1 comment 2 replies
-
At one point I would have thought so as well; I originally depended upon a couple of libraries (other than Yams) and would have liked the idea of splitting other useful pieces off into their own packages. When OpenAPIKit went through the process of becoming adopted by the Swift Server Work Group, I was convinced by the community that having OpenAPIKit be a low level package with no external dependencies would have more pros than cons. Side note: We discussed Yams being an exception because, although it's very much a dependency, it is only used by the test suite. I still stand by that assessment, though there are definitely both good and bad aspects to it. Fortunately, there's a viable option remaining: any part of OpenAPIKit is fair game (both in spirit and under the MIT license) for borrowing and using externally. The drawback doesn't escape me: instead of saving on maintenance work you double it (for the portion of borrowed code) and that's only if you choose not to subtly diverge with the new package's code which possibly further complicates maintenance. I hesitate to sign myself up to maintain such a fork of the JSONSchema support given my current OSS commitments and interests, but I would encourage and support anyone in the community who saw the benefits in creating a new work based on a part of OpenAPIKit and took it upon themselves to create such a package. |
Beta Was this translation helpful? Give feedback.
-
It would be great to extract the JSON Schema into a separate reusable library, for example, for AsyncAPI support.
Beta Was this translation helpful? Give feedback.
All reactions