Use kebab-case instead of SCREAMING_SNAKE_CASE for our string unions

[blaine-arcjet]

This will better align us with jco bindings.

We also want to support SCREAMING_SNAKE_CASE during a deprecation period.

[e-moran]

Will the deprecation period end when the beta begins?

Also how do we want to handle outputs that are currently in SCREAMING_SNAKE_CASE, eg detected pii entities and bot types. Its easy to support both inputs for the transition period, but for outputs its a bit tricker. We could convert back to screaming snake case when its detected for inputs but someone could just specify allow: [] and then its ambiguous.

[blaine-arcjet]

Will the deprecation period end when the beta begins?

I believe it'll be when we go RC.

I think the deprecation period is also marked as breaking for the cases you stated. We can only easily produce backwards compatibility for inputs but it is harder for outputs (we'd have to duplicate all values in both formats). TypeScript will help guide most people for the migrations.

[e-moran]

Will the deprecation period end when the beta begins?

I believe it'll be when we go RC.

I think the deprecation period is also marked as breaking for the cases you stated. We can only easily produce backwards compatibility for inputs but it is harder for outputs (we'd have to duplicate all values in both formats). TypeScript will help guide most people for the migrations.

Do you think it would be bad to just support backwards compatibility for inputs, because we can't do it consistently for outputs?

It would probably make users take the breaking change more seriously if we don't support it for outputs at all, so there's less likely to be issues for users in cases where we can't infer the casing scheme that they want.

[e-moran]

Pausing work on this while we await a response on bytecodealliance/jco#509 since we agree that it is better to avoid a migration for our users if possible

[e-moran]

It seems like jco will not allow us to make this change. This leaves us with three options:

1. We make the breaking change.
2. We do nothing, and leave the current translation layer as is.
3. We attempt to "fix" the generated bindings programmatically using a post-jco script.

We discussed why option one is unfavorable before, basically we would rather not force a breaking change on users where it isn't necessary.

Option three should work in theory, all of the string-enums that jco generates are either objects with a tag field or string unions. These can be identified programmatically and re-cased, however I could see this breaking at some point if jco makes changes.

I would like to make a decision on this soon so that we can progress the beta release.

cc @davidmytton

[davidmytton]

Agreed with your assessment. Option 3 sounds like it could break in the future so I suggest we stick with how it is now (option 2).

[e-moran]

Since we have decided not to make this change, I am closing this issue. Future work that would allow us to remove the translation layer is tracked by #2660.