Breaking change introduced by “Handle leading underscores in property names”

[biancabunaciu]

I believe the recent change to handle leading underscores in property names has introduced a breaking change in how the oapi-codegen generates structs. https://github.com/oapi-codegen/oapi-codegen/pull/1822

This renaming alters the generated code and breaks existing code that relies on the previous field names. While I understand the goal of avoiding duplicate names, this change modifies the generated code and therefore should be considered a breaking change.

Additionally, it exposes implementation details of the OpenAPI spec (like the underscore prefix) into the generated Go code, which can be undesirable when consumers expect normalized field names.

What I expected

The generated field names to stay consistent with previous behavior, or at least a clear note that this change breaks compatibility (e.g. via a major version bump or release note).

What happened

The generated code now prefixes fields with Underscore, breaking compatibility with previously generated code.

Suggestions

Maybe this behavior could be:

• Behind a flag, or
• Only enforced when duplicate fields are present, or
• Called out clearly in the changelog or release notes if it’s meant to be permanent

[jamietanna]

Thanks for the feedback.

Via , we didn't consider this a breaking change.

I'll get this explicitly documented in #2168 for the future as to what does/doesn't count as a breaking change

Additionally, it exposes implementation details of the OpenAPI spec (like the underscore prefix) into the generated Go code, which can be undesirable when consumers expect normalized field names.

Yes this is true - but if the spec is returning i.e. _version, then it may be expected by consumers that it may be named like so?

I've not seen how other generators (i.e. in Typescript, Java, etc) handle this sort of case, but it'd be interesting to hear what they would do.

Given this is a change inside typeNamePrefix, which is not currently wired in to be able to use CompatibilityOptions, I don't think we'll make it possible to opt-out of this change.

Only enforced when duplicate fields are present

This sounds reasonable - we'd welcome a PR to do so, which would also need a Compatibility Option to allow keeping the existing behavior.

It's also possible for you to work around this - in the meantime - by using an Overlay to add an x-go-name to override the generated type names