OpenAPITools / OpenAPITools/openapi-generator

[REQ] Enhancing generated Code by customising with YAML-Based Binding Files

Open
#19,427 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Enhancement: Feature
Dominant language
Java
Stars
26.8k
Forks
7.7k
PR merge metrics
PR metrics pending

Description

Is your feature request related to a problem? Please describe.

I'm always frustrated when the generated model classes do not look the way that I would have expected.

It is the nature of code generation that this can happen, but I would like to have the ability to influence the generated output more.

E. g. Injecting additional code has been a very useful thing in the past.

Describe the solution you'd like

I think there are two ways to cover this

  1. Vendor extensions inside of the YAML file

  2. additional binding files as they exist for XSD, code injection example

While having more vendor extensions could accomplish that I think it it has disadvantages:

a. it can grow very big, especially when injecting code

b. as a client, you'll get a YAML handed over and usually don't want to modify it to simplify the workflow of updating

So because especially because of b) I would propose a separate xjc-like binding file that allows to refine the generated code. Of course we do not like XML and would prefer an YAML version of it.

Describe alternatives you've considered

  1. Mustace templates: these alone do not handle non-generic changes that apply to single types only very good
  2. Vendor extensions: These could cover my wishes too, but at the moment there is no annotation like x-inject-code to add more code to the generated POJO.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No repository files, tests, or entry points are named. Start by reviewing the existing Mustache-template and vendor-extension customization paths mentioned in the issue, then define the scope and format of a YAML binding mechanism. Done would require an agreed design for targeted generated-code customization, including code injection.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, openapi, yaml
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.