Closed pyramation closed 2 years ago
https://github.com/nymlab/vectis/blob/main/contracts/govec/examples/schema.rs#L5
use cosmwasm_std::{Addr, Binary};
export_schema(&schema_for!(Binary), &out_dir);
re-opening, as it seems we shouldn't have to manually export Binary
. It seems to be inside of definitions
"definitions": {
"Binary": {
"description": "Binary is a wrapper around Vec<u8> to add base64 de/serialization with serde. It also adds some helper methods to help encode inline.\n\nThis is only needed as serde-json-{core,wasm} has a horrible encoding for Vec<u8>",
"type": "string"
},
"Empty": {
"description": "An empty struct that serves as a placeholder in different places, such as contracts that don't set a custom message.\n\nIt is designed to be expressable in correct JSON and JSON Schema but contains no meaningful data. Previously we used enums without cases, but those cannot represented as valid JSON Schema (https://github.com/CosmWasm/cosmwasm/issues/451)",
"type": "object"
},
here is the diff w and w/o manual binary export https://github.com/pyramation/cosmwasm-typescript-gen/pull/20
I'm finding some conflicts and hoping to resolve them. Seems that
Binary
should likely be aUtf8Array
.Part of the conflict, I'm realizing, is that a contract can export
Binary
(and evenCoin
), as it seems the vectis contracts are doing: https://github.com/pyramation/cosmwasm-typescript-gen/blob/master/packages/cosmwasm-typescript-gen/__output__/vectis/MyContractContract.ts#L64-L69