Problem

As we build new functionality into oapi-codegen, there are new features which should become the defaults, because they provide a much better experience.

For instance, using the new nullable support, but there are other features that are opt-in, such as those we are looking at making in the 3.x release.

However, we try to avoid changing the generated code for new features, and only plan to change the existing templated code if strictly necessary (i.e. to fix a bug).

So in this case, there's no handy way to "nudge" users to use the new functionality, aside from them having to read the docs and opt-in.

Waiting until 3.x (which will come with a slew of other breaking changes) is unlikely to be a good idea, especially as we have no idea when that will be (as noted in #1606)

However, we don't want to rely on users needing to do as much to get a better experience.

Solution

Instead, we should shamelessly take inspiration from Renovate's presets and introduce a means for users to take pre-configured set of defaults (separate to the actual defaults when using oapi-codegen with minimal configuration)

These will have a slightly different approach for stability, where generated changes will be possible, due to it having a slightly different behaviour to the "normal" defaults.

We should also define the "preset ladder", to indicate when a feature could be promoted to a "recommended" option.

Initial thoughts would be that a configuration item cannot enter the presets until at least 1 minor release later.

Out of scope

It will not be possible to create your own presets.

There will only be one preset, config:recommended.

It will be possible to use multiple presets (as an array format) but it will only be allowed to be a singleton, pending further decision on behaviour.