srdtrk / go-codegen Goto Github PK

Currently, if the contract_test.go file is missing the placeholder comment, then it will be overwritten when running add-contract.

Description

Currently, the testsuite only comes with wasmd v0.50.0. I'd like the interactive menu to allow users to select the chain's they'd like to use. I'll list the chains that should be supported:

• #87
• Add an option to generate osmosis in interchaintest
• Add an option to generate ibc-go simd v8.3 in interchaintest
• Add an option to generate gaia (Cosmos Hub) in interchaintest

And there are some other additional tasks that need to be completed:

• Add an interactive prompt to enable chain selection by the user.

This issue was introduced in v0.2.1 in here

Currently, in the feature branch, we can scaffold a testsuite using interchaintest scaffold command. Also add support for adding contracts with go-codegen interchaintest add contract [json_schema]

The CI should also run each test individually

e35b998 added grpc query clients but they are not currently used in the autogenerated testsuite

Similar to the other issue looks like it can parse array
https://github.com/public-awesome/cw-ics721/blob/main/packages/ics721/schema/ics721.json

9:22AM INF Generating code to cosmwasm/types/ics721/types.go
panic: unsupported type array for definition CallbackMsg_RedeemOutgoingChannelEntries

  {
            "description": "Redeem all entries in outgoing channel.",
            "type": "object",
            "required": ["redeem_outgoing_channel_entries"],
            "properties": {
              "redeem_outgoing_channel_entries": {
                "type": "array",
                "items": {
                  "type": "array",
                  "items": [
                    {
                      "$ref": "#/definitions/ClassId"
                    },
                    {
                      "$ref": "#/definitions/TokenId"
                    }
                  ],
                  "maxItems": 2,
                  "minItems": 2
                }
              }
            },
            "additionalProperties": false
          },

Would it be possible to pass a prefix when generating types? Ideally I'd like to have a single package and do something like

 go-codegen generate  cosmwasm/schemas/ics721.json --prefix ICS721 --output cosmwasm/types/ics721.go --package-name  types

 go-codegen generate  cosmwasm/schemas/cw721-base.json --prefix CW271 --output cosmwasm/types/cw721.go --package-name  types

Add a safety check that the correct go toolchain is available before generating the suite

There is a typo in the integration tests that is preventing dao-dao-core query client test from running, when this typo is fixed, the test is failing

Currently, response types are generated but the mapping between QueryMsg and its responses are left to the user

Following a comment on my last PR (#98), I've encountered an issue when generating schema types from our smart contract JSON schema.

To illustrate the problem, consider the following Rust code snippet:

/// # Value
#[cw_serde]
#[serde(tag = "type")]
pub enum Value {
    /// # String
    String { value: String },
    /// # Number
    Number { value: i64 },
}

{
  "contract_name": "nested-enum-same-name",
  "contract_version": "0.0.1",
  "idl_version": "1.0.0",
  "instantiate": {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "InstantiateMsg",
    "description": "Instantiate message",
    "type": "object",
    "additionalProperties": false
  },
  "execute": {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "ExecuteMsg",
    "description": "Execute messages",
    "oneOf": [
      {
        "title": "Foo",
        "type": "object",
        "required": [
          "foo"
        ],
        "properties": {
          "foo": {
            "type": "object",
            "required": [
              "value"
            ],
            "properties": {
              "value": {
                "$ref": "#/definitions/Value"
              }
            },
            "additionalProperties": false
          }
        },
        "additionalProperties": false
      }
    ],
    "definitions": {
      "Value": {
        "title": "Value",
        "oneOf": [
          {
            "title": "String",
            "type": "object",
            "required": [
              "type",
              "value"
            ],
            "properties": {
              "type": {
                "type": "string",
                "enum": [
                  "string"
                ]
              },
              "value": {
                "type": "string"
              }
            },
            "additionalProperties": false
          },
          {
            "title": "Number",
            "type": "object",
            "required": [
              "type",
              "value"
            ],
            "properties": {
              "type": {
                "type": "string",
                "enum": [
                  "number"
                ]
              },
              "value": {
                "type": "integer",
                "format": "int64"
              }
            },
            "additionalProperties": false
          }
        ]
      }
    }
  },
  "query": {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "QueryMsg",
    "description": "Query messages",
    "oneOf": [
      {
        "title": "Bar",
        "type": "object",
        "required": [
          "bar"
        ],
        "properties": {
          "bar": {
            "type": "object",
            "required": [
              "foo"
            ],
            "properties": {
              "foo": {
                "type": "string"
              }
            },
            "additionalProperties": false
          }
        },
        "additionalProperties": false
      }
    ]
  },
  "migrate": null,
  "sudo": null,
  "responses": {
    "bar": {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "title": "BarResponse",
      "type": "object",
      "required": [
        "foo"
      ],
      "properties": {
        "foo": {
          "description": "The foo value",
          "type": "string"
        }
      },
      "additionalProperties": false
    }
  },
  "description": "# nested-enum-same-same",
  "title": "nested-enum-same-same"
}

Internally tagged enum

In this code, we're using the serde tag #[serde(tag="type")] to transform the representation of our enum into an internally tagged format, as described in the serde documentation. This results in a generated JSON schema with an enum Type that can take string or number as a value.

Here's a snippet of the generated JSON schema:

<...>
       {
            "title": "String",
           <...>
            "properties": {
              "type": {
                "type": "string",
                "enum": [
                  "string"
                ]
              },
              "value": {
                "type": "string"
              }
            },
          },
          {
            "title": "Number",
          <...>
            "properties": {
              "type": {
                "type": "string",
                "enum": [
                  "number"
                ]
              },
              "value": {
                "type": "integer",
                "format": "int64"
              }
            },
          }

I've created a branch on a fork that includes a fix for merging multiple enums with the same name in the definition registry. This situation arises here because the possible values of the Type enum are defined in each definition of the Value enum. You can find the fix in this commit: d210cad.

Struct enum with same attribute name

Another issue arises because each enumeration struct variant contains a value property with a different type. When generating code with go-codegen, this leads to the following error:

duplicate definition `Value_Value` with differing implementations: different types [string] != [integer]

The issue arises due to a conflict in the type registration of Value_Value in the definition registry. Initially, Value_Value was registered as a string type. However, an attempt to register it again as an integer type has led to this problem.

For a more comprehensive understanding of the issue, you can refer to the original JSON schema that triggered this problem. It is available here. The corresponding representation in the Rust contract can be found here.

This should contain constants such as the StartingTokenAmount

I don't like github workflows that generate code and push, which go-codegen can be used to create. Instead, I like workflows that check validity.

Therefore, I want to add a --check flag where go-codegen checks whether or not the output file provided (with -o flag) matches the output of the program.

This bug was introduced in v0.2.0 in here

When I try generating types for the latest main branch of cw-nfts I get this error panic: response get_withdraw_address is not supported, please create an issue in https://github.com/srdtrk/go-codegen

      {
        "type": "object",
        "required": ["get_withdraw_address"],
        "properties": {
          "get_withdraw_address": {
            "type": "object",
            "additionalProperties": false
          }
        },
        "additionalProperties": false
      }

We should be able to auto-generate an interchaintest test suite.

In go-codegen interchaintest add-contract, you set a custom package name using '--contract-name'. I think this is not descriptive.

It seems that the autogenerated github actions can't auto upload the diagnostics since it is pointing to the wrong directory.

I've been working on this feature for a while, adding this as a tracking issue now. The testsuite is based on interchaintest.

In interchaintest v8.3. This is provided by chain.AuthQueryModuleAddress

This will be helpful once we allow variable versions of wasmd.

The manual amount is too low and the default is even higher anyway.

Currently, the package name is the contract name with all non alphabetic characters removed. Improve this by:

• Allowing numbers
• Converting all capital letters to lower case.

@kakucodes brought this to my attention. Tag a release once this is resolved.
dao-dao-core.json

Right now, there are no tests for it, and there were some bugs in it.

Right now, the package name is hard coded to cwicacontroller. This is a bug

Actions are still using 1.21

When two types have the same name, the codegen often breaks down. This likely requires a deep refactor of this messy code. See this schema file as an example:
cw-ibc-lite-ics02-client.json