You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many people define references in OpenAPI files such that those references are not internal to the OpenAPI file. As a result, they expect that when they use the openapi-merge library or CLI tool, that it will merge everything together for them.
We could solve this problem in one of two ways:
Pre-bundle all of the references into each individual OpenAPI file and then rely upon de-duplication to end up with a minimal OpenAPI file.
Support external references such that the merging algorithm can load them all itself and then bundle only the components that are required.
At this point in time. I think that I have a preference for Option 1 because it means that we can offload this problem to another tool and then just ask people to integrate that together instead to form a cohesive whole. It is a nice way to introduce composition into the flow with a bunch of specific tools that compose together nicely. We can also then just make the CLI tool integrate that by default so that the CLI tool works like people expect.
It is also worth noting that the merge function currently expects all of the OpenAPI files to be pre-downloaded, that allows that function to be synchronous (which is good and reduces complexity). Attempting to load the schemas while we loaded external schemas would be an architectural mistake, because it would be a poor separation of concerns. Instead the merge function could be modified to have a pre-downloaded mapping of Reference => Schema that it can use in a synchronous manner.
The text was updated successfully, but these errors were encountered:
Many people define references in OpenAPI files such that those references are not internal to the OpenAPI file. As a result, they expect that when they use the
openapi-merge
library or CLI tool, that it will merge everything together for them.We could solve this problem in one of two ways:
At this point in time. I think that I have a preference for Option 1 because it means that we can offload this problem to another tool and then just ask people to integrate that together instead to form a cohesive whole. It is a nice way to introduce composition into the flow with a bunch of specific tools that compose together nicely. We can also then just make the CLI tool integrate that by default so that the CLI tool works like people expect.
It is also worth noting that the
merge
function currently expects all of the OpenAPI files to be pre-downloaded, that allows that function to be synchronous (which is good and reduces complexity). Attempting to load the schemas while we loaded external schemas would be an architectural mistake, because it would be a poor separation of concerns. Instead themerge
function could be modified to have a pre-downloaded mapping ofReference => Schema
that it can use in a synchronous manner.The text was updated successfully, but these errors were encountered: