Using generated Clojure library fails due to non-existent requires

[njerig]

I'm using openapi-generator v.7.5.0-snapshot (due to an issue I helped resolve) to generate a Plaid Clojure library. Sadly, generated Clojure libraries do not come with tests, so I'd either have to write them myself (tough, since the API is large) or just handle bugs as I encounter them when using the library in a side project I'm building.

I'm generating the library with the following command:
openapi-generator generate -g clojure -i 2020-09-14.yml -o ./build/plaid-clj -p projectName=plaid-clj,sortParamsByRequiredFlag=true

When I try to use the generated library in the side project, errors are returned due to non-existent spec namespaces being required in ./build/plaid-clj/src/plaid_clj/api/plaid.clj. When I looked into which specs were not being generated, I noticed models of simple types like "string" were not generated.

So far, I've been preprocessing the OpenAPI YAML spec (2020-09-14.yml) with a Python script and adding a key for whether a certain model is of a simple type, then only including requires for models for which that key is falsey. However, I'm wondering whether perhaps a regex or something else can be added to the OpenAPI YAML spec so that specs are also generated for simple types (since these models normally have a format associated with them). (This is basically what #60 is suggesting.) Otherwise, could you recommend a way forward?

[phoenixy1]

So I don't know anything about Clojure, and I don't know very much about client library generation, but I'll do my best to answer:

If the Openapi-generator needs the format strings in order to generate the library, I'd suggest adding very generic regex formats (that accept any string) to the strings that don't have them. This isn't something we currently plan to add on our end since a) the official libraries don't need them and b) in general, we are very reluctant to add additional validation on the client side, because it makes change management in the API very difficult -- we need to be able to update the API without making changes that will be breaking for customers on old client library versions. Since it sounds like you are already doing pre-processing of the openapi file, it seems like this is is something you could do as part of the pre-processing step.

Does that work for your use case?

[njerig]

It turns out I can edit the Mustache templates and filter out imports of models that are of primitive types. No preprocessing needed.

Thanks for the help.