feat: add protoJsonFormat option to support standard Protobuf JSON message

[guglielmo-san]

The Protobuf JSON Mapping specification requires that messages parsers accept both the lowerCamelCase name (or explicit json_name) and the original proto field name (often snake_case) when parsing JSON. Before this change, ts-proto's fromJSON generated method only supported one format based on the snakeToCamel configuration, typically prioritizing camelCase.

Mechanism: This PR introduces a new boolean option: protoJsonFormat. When enabled:

• snakeToCamel includes json, enforcing typical camelCase keys for output (toJSON).
• fromJSON is enhanced to check for both the standard JSON name (camelCase or json_name) and the original proto field name.
• If the two names are identical, no extra check is generated to avoid code bloat.

Example:

message Message {
  string my_field = 1;
  string second_field = 2 [json_name = "myCustomName"];
}

Generated fromJSON:

  fromJSON(object: any): Message {
    return {
      myField: isSet(object.myField)
        ? globalThis.String(object.myField)
        : isSet(object.my_field)
        ? globalThis.String(object.my_field)
        : "",
      secondField: isSet(object.myCustomName)
        ? globalThis.String(object.myCustomName)
        : isSet(object.second_field)
        ? globalThis.String(object.second_field)
        : "",
    };
  }

Changes:

• Added protoJsonFormat to Options.
• Updated src/main.ts fromJSON generation generation logic to include fallback che
• Added comprehensive integration tests in integration/proto-json-format/.

Fixes #1012

This change is required to adopt the ts-proto library in the A2A-js project

[stephenh]

Hi @guglielmo-san ; thanks for the PR, this looks great!

Given you're making ts-proto more spec compliant, I'm kinda wondering if we should default this new option to true, and then allow users who really actively don't want the fallback/spec behavior, to turn it off by setting =false.

Particularly since you made the output conditional on fieldName !== jsonName, which I really appreciate it.

Does that sound good to you?

Otherwise I think just a small diff error in the CI build, and once that is fixed I'll hit merge -- thanks again!

[stephenh]

Apologies for the hassle here @guglielmo-san , but with the default flipped, it looks like all the codegen files will need pushed into the PR -- sorry this can seem like a pita, but its a form our of "regression tests" to see how each PR affects the generated code output, given that is our primary deliverable. :-)

Thank you!

[guglielmo-san]

Hi @stephenh , yes it is a good idea to have the protoJsonFormat as default behavior. I updated the value and the README and generated again all the .ts files in the integration tests.
Now the workflows should pass successfully.

[stephenh]

This is great @guglielmo-san , hitting merge -- thanks again!

[stephenh]

🎉 This PR is included in version 2.11.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release
• v2.11.0

Your semantic-release bot 📦🚀