Ques: Is there a reason to force the operationId to camelcase

[abhishekdev]

Question

Is there a reason to force the operationID to camelcase?

Current Behavior
e.g. A operation ID like EvaluateUserIAM will get generated as evaluateUserIam

Expected behavior
Based on the spec guide (reffered below) I guess if an operation ID is found on the schema it should not be mutated.

The openID spec mentions that the operation ID is case sensitive, however since the generator is mutating the operation name to be camelcase it causes confusion for consuming clients.

Source Reference

oazapfts/packages/codegen/src/generate.ts

Lines 120 to 125 in 702c400

	export function getOperationIdentifier(id?: string) {
	if (!id) return;
	if (id.match(/[^\w\s]/)) return;
	id = _.camelCase(id);
	if (cg.isValidIdentifier(id)) return id;
	}

[Xiphe]

I tend to say: Probably no specific reason.

For me this makes sense though as Commonly in javascript/typescript functions and methods start with a lower case and only classes and types use uppercase.

[abhishekdev]

Thanks for sharing your thoughts @Xiphe.

It seems there is already a graceful fallback built into the logic to check for invalid JS/TS characters (i.e. regex + isValidIdentifier check). Given these checks are in place, should JS code convention override the spec at this code generation layer though?

As long as valid code is generated, I guess the API naming spec (=> source of truth) should be given precedence which might be using its own contextual naming convention. Thoughts?

e.g. Even if the the API name is evaluateUserIAM, the current naming would force it to evaluateUserIam. creating a cognitive load for the users consuming the same API over different platforms (via different code generators).

PS: My personal opinion would be to not use acronyms/abbreviations like such in camelcase strings to help with readability. But convention like this is a challenge to enforce for API's one does not control and the OpenAPI specs defining the field as case-sensitive

[Xiphe]

I get your point and principally agree.

Please bare in mind that when we change this, it will potentially have wide-ranging impacts. It would potentially cause a lot of breaking changes for the clients generated. I'd therefore move this behind a feature flag to opt-into rather then change default behavior.

With this in mind, personally I find the additional cognitive load negligible as such I'm not sure If the additional complexity on this system is worth it.

I'd still be open to learn if others would also be interested in having this behavior. Might also be a good case for the Plugin System that @fimion is currently championing. (For this se should maybe add a naming related hook)

[fimion]

Yeah, we could probably add a naming hook. We would need to specify the type of thing we are naming, but then you could handle it how you want to.

[abhishekdev]

I agree! Changing this should definitely considered as a breaking change.

The ability to opt-in is a reasonable path forward.

The concept of the "plugin system" sounds very interesting. I'll take a look over the weekend and If I can contribute.