docs: improve command descriptions #399
Conversation
📝 WalkthroughWalkthroughAdds or refines CLI summaries/descriptions across many commands. Introduces new subcommands for Solana (encode) and ZetaChain (withdraw-and-call). Updates option help texts, notably for ZetaChain helpers. EVM deposit command gains a description, new --erc20 option, schema validation, and an action handler that invokes main. No other runtime logic changes. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User
participant CLI as CLI (evm deposit)
participant Validator as Schema Validator
participant Main as deposit.main()
participant RPC as EVM RPC/ZetaChain
User->>CLI: evm deposit --amount ... [--erc20 ...] ...
CLI->>Validator: validateAndParseSchema(options)
alt valid options
Validator-->>CLI: validatedOptions
CLI->>Main: main(validatedOptions)
Main->>RPC: Submit deposit tx (erc20/native)
RPC-->>Main: Tx hash / receipt
Main-->>CLI: Result
CLI-->>User: Output status/details
else invalid options
Validator-->>CLI: errors (exitOnError)
CLI-->>User: Show validation errors and exit
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/commands/src/query/chains/show.ts (1)
349-354: Fix mutual exclusion to reference the correct option nameThe
conflicts()call on the--chain-idoption currently references"chain", which doesn’t exist. It needs to reference the long name of the other option ("chain-name") to enforce mutual exclusivity. No other occurrences ofconflicts(["chain"])were found in the repository.• File:
packages/commands/src/query/chains/show.ts
Line 353: update the conflict targetSuggested patch:
.addOption( new Option("--chain-name <chain>", "Chain name").conflicts(["chain-id"]) ) .addOption( - new Option("-c, --chain-id <chain-id>", "Chain ID").conflicts(["chain"]) + new Option("-c, --chain-id <chain-id>", "Chain ID").conflicts(["chain-name"]) )
🧹 Nitpick comments (39)
packages/commands/src/ton/depositAndCall.ts (1)
79-81: Prefer “native TON” in the summary to avoid confusion with JettonsThe command takes an amount “in TON” and has no token/mint option, so “native TON” is clearer and consistent with the description line below.
- .summary("Deposit TON and call a contract on ZetaChain") + .summary("Deposit native TON and call a contract on ZetaChain")packages/commands/src/accounts/delete.ts (2)
56-58: Description states both type and name are required; reflect that in the CLI surfaceSince validation requires both fields, marking --type as mandatory in the CLI will align the UX with the description and reduce user error.
60-61: Make --type mandatory to match validation and descriptionCommander can enforce this at the option level without changing runtime behavior.
- .addOption( - new Option("--type <type>", "Chain type").choices(AvailableAccountTypes) - ) + .addOption( + new Option("--type <type>", "Chain type") + .choices(AvailableAccountTypes) + .makeOptionMandatory(true) + )packages/commands/src/solana/depositAndCall.ts (1)
72-75: Be explicit: “SPL tokens” in the summaryYou already expose --mint and token program; calling out “SPL tokens” improves precision and mirrors Solana terminology.
- .summary("Deposit tokens from Solana and call a contract on ZetaChain") + .summary("Deposit SPL tokens from Solana and call a contract on ZetaChain")packages/commands/src/ton/deposit.ts (1)
72-73: Use “TON/native TON” instead of “tokens” for accuracyThis command accepts “Amount in TON” and has no token/mint option, so “TON” (or “native TON”) is less ambiguous than “tokens.”
- .summary("Deposit tokens from TON") - .description("Deposit tokens to an EOA or a contract on ZetaChain") + .summary("Deposit TON to ZetaChain") + .description("Deposit native TON to an EOA or a contract on ZetaChain")packages/commands/src/query/tokens/list.ts (3)
97-99: Help text reads well; slight tightening and cross-reference to --columns could improve discoverabilityConsider making the description mention the optional columns so users discover them without scanning options.
Apply this minimal copy tweak:
- .summary("List all ZRC-20 tokens") - .description("Fetch and display all registered ZRC-20 tokens on ZetaChain") + .summary("List all ZRC-20 tokens") + .description("Fetch and display registered ZRC-20 tokens on ZetaChain. Use --columns to include Asset, Type, and Decimals in the table")
102-102: JSON flag copy is fine; optional brevity“Output in JSON format” is clear. If you prefer brevity across help, “Output JSON” is a common pattern used elsewhere in CLIs.
- .option("--json", "Output in JSON format") + .option("--json", "Output JSON")
104-107: Add explicit column names to the CLI help textWe’ve confirmed that
tokensListOptionsSchemadefinescolumns: z.array(z.enum(["asset", "type", "decimals"])).default([])which exactly matches the Commander
choicesand default (empty array). To improve UX by surfacing the available options directly in the help string, please update the--columnsdescription:File: packages/commands/src/query/tokens/list.ts
- new Option("--columns <values...>", "Additional columns to display") + new Option("--columns <values...>", "Additional columns to display (asset, type, decimals)")packages/commands/src/bitcoin/inscription/index.ts (1)
10-12: Clarify where contracts are calledExplicitly naming the target chain avoids ambiguity for users unfamiliar with the flow.
- .description( - "Use Bitcoin inscriptions to deposit BTC to ZetaChain or call contracts" - ) + .description( + "Use Bitcoin inscriptions to deposit BTC to ZetaChain or call contracts on ZetaChain" + )packages/commands/src/accounts/create.ts (1)
34-38: Avoid hardcoding the default account name in descriptionInterpolate DEFAULT_ACCOUNT_NAME to keep help text in sync if the constant changes.
- .description( - `Generates a new account for the specified chain type. - -You can name the account for easier identification; if no name is provided, it defaults to default.` - ) + .description( + `Generates a new account for the specified chain type. + +You can name the account for easier identification; if no name is provided, it defaults to ${DEFAULT_ACCOUNT_NAME}.` + )packages/commands/src/faucet.ts (2)
37-38: Differentiate summary vs description to add contextUsing the same sentence for both works, but the description can briefly explain address resolution to reduce user confusion.
.summary("Request testnet ZETA tokens from the faucet") - .description("Request testnet ZETA tokens from the faucet") + .description("Request testnet ZETA tokens from the faucet. Provide --address or let the tool resolve it from an account name")
40-41: Align punctuation/style with repo conventions; clarify EVMOther options drop trailing periods. Also, the resolution path uses resolveEvmAddress, so naming EVM explicitly helps.
- new Option("--address <address>", "Recipient address.").conflicts(["name"]) + new Option("--address <address>", "Recipient EVM address").conflicts(["name"])packages/commands/src/sui/index.ts (1)
8-11: Tighten phrasing; avoid repeating “deposit” and clarify contract targetMinor copy tweak to make the description read smoothly and name the target chain explicitly.
- .summary("Deposit tokens and call universal contracts from Sui") - .description( - "Interact from Sui: deposit tokens to ZetaChain or deposit and call contracts" - ) + .summary("Deposit tokens and call universal contracts from Sui") + .description( + "Interact from Sui: deposit tokens to ZetaChain or call contracts on ZetaChain" + )packages/commands/src/bitcoin/memo/index.ts (1)
9-11: Tighten description and align with terminology used elsewhere (“universal contract”).Minor wording tweak for clarity and consistency with Solana/Bitcoin call commands.
.description( - "Use OP_RETURN memo to deposit BTC to ZetaChain or call contracts" + "Use an OP_RETURN memo to deposit BTC to ZetaChain or call a universal contract" )packages/commands/src/query/chains/list.ts (1)
141-147: Standardize summary punctuation across commands.This summary lacks a terminal period, while other commands (e.g., cctx) include one. Consider picking one style repo‑wide for consistency (with or without a period) and applying it here.
packages/commands/src/accounts/show.ts (1)
47-47: Rename option label to “Chain type” to match description and other accounts commands.Other account commands in this PR use “Chain type,” and your new description also references “chain type.” Align the label here.
- .addOption( - new Option("--type <type>", "Account type").choices(AvailableAccountTypes) - ) + .addOption( + new Option("--type <type>", "Chain type").choices(AvailableAccountTypes) + )packages/commands/src/evm/call.ts (1)
92-95: Make the description consistent with Solana’s wording (“universal contract”).Small copy edit for cross‑command consistency.
export const callCommand = new Command("call") .summary("Call a contract on ZetaChain from an EVM-compatible chain") - .description("Call a contract on ZetaChain from an EVM-compatible chain"); + .description("Call a universal contract on ZetaChain from an EVM-compatible chain");packages/commands/src/query/fees.ts (1)
80-81: Nit: spinner message mentions “foreign coins,” consider aligning with fees contextThe runtime spinner still says “Fetching foreign coins...”, which can be confusing in a fees-focused command.
Suggested tweak elsewhere in this file:
// Before const spinner = options.json ? null : ora("Fetching foreign coins...").start(); // After const spinner = options.json ? null : ora("Fetching gas fees...").start();packages/commands/src/accounts/import.ts (1)
36-39: Nit: prefer “keystore” and tighten wordingMinor terminology and style improvement for consistency with common usage.
Apply:
- `Adds an account to the local key store using a private key or mnemonic phrase. - -You can choose the chain type and give the account a name.` + `Adds an account to the local keystore using a private key or mnemonic phrase. + +Choose the chain type and assign a name to the account.`packages/commands/src/query/chains/show.ts (1)
356-357: Nit: conventional flag order for Option flagsCommander examples typically use “-f, --field ”. This also matches tokens/show.ts after your edits.
Apply:
- .addOption( - new Option("--field -f <field>", "Return only a specific field value") - ) + .addOption( + new Option("-f, --field <field>", "Return only a specific field value") + )packages/commands/src/evm/depositAndCall.ts (1)
108-114: Nit: avoid duplicating summary and description; make description more informativeCurrently both strings are identical. Suggest a short summary and a richer description that mentions ERC-20/native support and ABI types/values.
Apply:
export const depositAndCallCommand = new Command("deposit-and-call") - .summary( - "Deposit tokens and call a contract on ZetaChain from an EVM-compatible chain" - ) - .description( - "Deposit tokens and call a contract on ZetaChain from an EVM-compatible chain" - ); + .summary("Deposit and call a contract on ZetaChain (EVM)") + .description( + "Deposit native or ERC-20 tokens from an EVM-compatible chain and call a universal contract on ZetaChain. Provide ABI types and values for the function invocation." + );Additionally, consider spelling “ERC-20” with a hyphen in the option help for consistency with “ZRC-20” elsewhere.
packages/commands/src/query/tokens/show.ts (2)
146-149: Nit: punctuation and readability in descriptionUse a period instead of a semicolon and split into two sentences for clarity.
Apply:
- .description( - "Display detailed information about a specific ZRC-20 token by symbol; supports returning a single field for scripting" - ) + .description( + "Display detailed information about a specific ZRC-20 token by symbol. Supports returning a single field for scripting." + )
161-163: Nit: conventional flag order for Option flagsPrefer “-f, --field ” for consistency with common Commander patterns (and with chains/show suggestion).
Apply:
.addOption( - new Option( - "--field -f <field>", + new Option( + "-f, --field <field>", "Return only a specific field value. Use 'zrc20' as shorthand for 'zrc20_contract_address'" ) )packages/commands/src/query/balances.ts (1)
176-183: Keep CLI help consistent: add TON to the wallet error bannerYou added the
--tonoption to the command help, but the WALLET_ERROR guidance still omits TON. Users who see the error will miss the TON hint.Apply this diff to include TON in the banner:
To resolve this issue, please choose one of these options: 1. Provide wallet addresses directly with command arguments: --evm <address> --solana <address> --bitcoin <address> --sui <address> + --ton <address>Also applies to: 190-190
packages/commands/src/evm/deposit.ts (2)
88-91: Avoid repeating the summary; make the description more actionableDescription currently duplicates the summary. Consider adding detail about native vs ERC‑20 deposits so help output is more informative.
export const depositCommand = new Command("deposit") .summary("Deposit tokens to ZetaChain from an EVM-compatible chain") - .description("Deposit tokens to ZetaChain from an EVM-compatible chain"); + .description( + "Deposit native tokens or ERC-20 tokens from an EVM-compatible chain to ZetaChain." + );
93-97: Clarify units and intent for amount/token optionsSmall copy tweak to reduce ambiguity for users about what “amount” represents and when to use
--erc20..requiredOption("--amount <amount>", "Amount of tokens to deposit") .option( "--erc20 <address>", - "ERC20 token address (optional for native token deposits)" + "ERC-20 token address (omit for native token deposits)" )Alternatively:
- .requiredOption("--amount <amount>", "Amount of tokens to deposit") + .requiredOption( + "--amount <amount>", + "Amount to deposit (in native token or ERC‑20 units)" + )utils/zetachain.command.helpers.ts (1)
238-241: Remove trailing space in help textMinor polish: there’s an extra space at the end of the description string.
.option( "--revert-message <message>", - "Message to include in the revert call ", + "Message to include in the revert call", "0x" )packages/commands/src/query/tokens/index.ts (1)
8-11: Tighten wording; use imperative voice for consistency with other commandsCurrent phrasing is descriptive (“Provides commands to…”). Most other help texts in this PR use an imperative style. Suggest a small reword for brevity and consistency.
- .summary("Work with tokens on ZetaChain") - .description( - "Provides commands to list all available ZRC-20 tokens or view detailed information about a specific token. Useful for discovering token metadata, contract addresses, and supported chains." - ) + .summary("Query tokens on ZetaChain") + .description( + "List ZRC-20 tokens or show details for a specific token (metadata, contract addresses, supported chains)." + )packages/commands/src/accounts/list.ts (2)
35-38: Unify terminology with accounts/index.ts (“key management system”) and trim fillerElsewhere (accounts/index.ts) you use “CLI’s key management system.” Mirror that phrasing here and drop “currently” to reduce noise.
- .summary("List all stored accounts") - .description( - `Display all accounts currently stored locally in the CLI key store` - ) + .summary("List all stored accounts") + .description( + `Display all accounts stored locally in the CLI's key management system` + )
21-31: JSON mode should emit valid JSON even when no accounts existWhen --json is passed and there are zero accounts, the command prints “No accounts found.” (a string) rather than an empty JSON array. This breaks machine consumption and is inconsistent with typical CLI JSON modes.
- if (accounts.length === 0) { - console.log("No accounts found."); - return; - } - - if (json) { - console.log(JSON.stringify(accounts, null, 2)); - } else { - console.log("\nAvailable Accounts:"); - console.table(accounts); - } + if (json) { + // Always emit JSON for machine readability + console.log(JSON.stringify(accounts, null, 2)); + return; + } + + if (accounts.length === 0) { + console.log("No accounts found."); + return; + } + + console.log("\nStored accounts:"); + console.table(accounts);Note: The label was also adjusted to “Stored accounts:” to match the summary.
packages/commands/src/accounts/index.ts (1)
10-15: Align tone and terminology; simplify multi-line descriptionSwitch to imperative voice (“Manage…”) and keep the “key management system” terminology consistent with list.ts. Also collapse excess whitespace in the template literal.
- .summary("Manage accounts for all connected chains") - .description( - `Manages accounts for all connected chains in the ZetaChain CLI. Supports creating new accounts, importing existing ones, listing all accounts, showing details, and deleting accounts. - -Accounts are stored locally in the CLI's key management system and can be used across all supported networks.` - ) + .summary("Manage accounts for all connected chains") + .description( + `Manage accounts across all connected chains in the ZetaChain CLI. Create, import, list, show, and delete accounts. +Accounts are stored locally in the CLI's key management system and can be used across all supported networks.` + )packages/commands/src/solana/index.ts (1)
9-17: Encode command wiring verified; optional copy tweak available
- ✅ The file
packages/commands/src/solana/encode.tsexists and correctly exportsencodeCommand.- ✅
encodeCommandis instantiated as anew Command("encode"), so it will be wired into the CLI without runtime help errors.You may optionally apply this small polish to the
.description()text for improved readability:- .summary("Deposit tokens and call universal contracts from Solana") - .description( - "Interact from Solana: call contracts on ZetaChain or deposit tokens (with or without a call)." - ) + .summary("Deposit tokens and call universal contracts from Solana") + .description( + "Interact from Solana by calling contracts on ZetaChain or depositing tokens (with or without a call)." + )packages/commands/src/bitcoin/index.ts (1)
7-10: Polish phrasing for OP_RETURN for clarity and consistency.Tiny grammar tweak; add an article before “OP_RETURN memo.” Keeps style consistent with other command texts.
.description( - "Work with Bitcoin to deposit BTC to ZetaChain or call contracts using inscriptions or OP_RETURN memo." + "Work with Bitcoin to deposit BTC to ZetaChain or call contracts using inscriptions or an OP_RETURN memo." )packages/commands/src/evm/index.ts (1)
8-11: Consider naming token types explicitly to align with the new --erc20 option.Since deposit now supports ERC-20 explicitly, calling that out improves help discoverability.
.description( - "Interact from EVM chains: call contracts on ZetaChain or deposit tokens (with or without a call)." + "Interact from EVM chains: call contracts on ZetaChain or deposit native or ERC-20 tokens (with or without a call)." )packages/commands/src/query/chains/index.ts (1)
8-11: Use imperative voice and add a comma for readability.Matches typical CLI help style used elsewhere.
.description( - "Provides commands to list all chains connected to ZetaChain or view details about a specific chain by name or chain ID." + "List all chains connected to ZetaChain, or view details for a specific chain by name or chain ID." )packages/commands/src/zetachain/withdrawAndCall.ts (1)
152-152: Minor clarity and style nits: add “from ZetaChain” in the summary and switch “example” → “e.g.” to match nearby option text.These tweaks harmonize with the description (which already says “from ZetaChain”) and with the “e.g.” wording used for --types.
-export const withdrawAndCallCommand = new Command("withdraw-and-call").summary( - "Withdraw tokens and call a contract on a connected chain" +export const withdrawAndCallCommand = new Command("withdraw-and-call").summary( + "Withdraw tokens from ZetaChain and call a contract on a connected chain" ); .option( "--function <function>", - `Function signature to call (example: "hello(string)")` + `Function signature to call (e.g., "hello(string)")` )Also applies to: 156-158, 162-162
packages/commands/src/query/index.ts (1)
11-16: Polish help copy: shorter summary + imperative voice in descriptionOptional copy edit to make the help tighter and more action-oriented. Also removes “You can” phrasing.
- .summary("Query ZetaChain data and connected chain information") + .summary("Query data on ZetaChain and connected chains") .description( - `Provides a set of tools to fetch on-chain data from ZetaChain and its connected chains. - -You can retrieve balances, token information, supported chain details, cross-chain transaction status, and fee estimates for cross-chain operations.` + `Fetch on-chain data from ZetaChain and its connected chains. + +Retrieve balances, token information, supported chain details, cross-chain transaction status, and fee estimates for cross-chain operations.` )packages/commands/src/zetachain/call.ts (2)
137-140: Minor copy edit: use imperative mood for consistency with CLI help styleImperative mood is commonly used in command help. Suggested tweak below; feel free to keep as-is if your style guide prefers third person.
.summary("Call a contract on a connected chain from ZetaChain") .description( - "Executes a contract call from ZetaChain to a connected chain without transferring tokens. You can specify the destination contract, function signature, parameters, and advanced options like revert handling and gas settings." + "Execute a contract call from ZetaChain to a connected chain without transferring tokens. Specify the destination contract, function signature, parameters, and advanced options like revert handling and gas settings." )
151-155: Good use of conflicts; clarify data format and add XOR validation at schema level
- Nice:
.conflicts(["types","values","function"])correctly prevents mixing raw data with ABI params.- Suggest clarifying the expected format of
--datain the help text (it’s validated as a hex string).- Optional but useful: Add a schema-level XOR guard so users must provide either
--dataor--function(with types/values), preventing runtime fallthrough when nothing is specified.Help text tweak (current hunk):
- .addOption( - new Option("--data <data>", "Raw data").conflicts([ + .addOption( + new Option( + "--data <data>", + "Raw ABI-encoded calldata (hex string)" + ).conflicts([ "types", "values", "function", ])Additionally, apply this schema refinement outside this hunk to enforce XOR semantics (either
--dataor--function):const callOptionsSchema = baseZetachainOptionsSchema .extend({ data: hexStringSchema.optional(), function: z.string().optional(), types: stringArraySchema.optional(), values: stringArraySchema.optional(), }) .refine(typesAndValuesLengthRefineRule.rule, { message: typesAndValuesLengthRefineRule.message, path: typesAndValuesLengthRefineRule.path, }) .refine(functionTypesValuesConsistencyRule.rule, { message: functionTypesValuesConsistencyRule.message, path: functionTypesValuesConsistencyRule.path, }) .refine(namePkRefineRule) .refine(rpcOrChainIdRefineRule.rule, { message: rpcOrChainIdRefineRule.message, - }); + }) + .refine( + (o) => Boolean(o.data) || Boolean(o.function), + { + message: + "Provide either --data or --function (with --types and --values).", + } + );Would you like me to propagate the “hex string” clarification to any sibling commands that accept raw calldata?
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (37)
packages/commands/src/accounts/create.ts(1 hunks)packages/commands/src/accounts/delete.ts(1 hunks)packages/commands/src/accounts/import.ts(1 hunks)packages/commands/src/accounts/index.ts(1 hunks)packages/commands/src/accounts/list.ts(1 hunks)packages/commands/src/accounts/show.ts(1 hunks)packages/commands/src/bitcoin/index.ts(1 hunks)packages/commands/src/bitcoin/inscription/index.ts(1 hunks)packages/commands/src/bitcoin/memo/index.ts(1 hunks)packages/commands/src/evm/call.ts(1 hunks)packages/commands/src/evm/deposit.ts(1 hunks)packages/commands/src/evm/depositAndCall.ts(1 hunks)packages/commands/src/evm/index.ts(1 hunks)packages/commands/src/faucet.ts(1 hunks)packages/commands/src/program.ts(1 hunks)packages/commands/src/query/balances.ts(1 hunks)packages/commands/src/query/cctx.ts(1 hunks)packages/commands/src/query/chains/index.ts(1 hunks)packages/commands/src/query/chains/list.ts(1 hunks)packages/commands/src/query/chains/show.ts(2 hunks)packages/commands/src/query/fees.ts(1 hunks)packages/commands/src/query/index.ts(1 hunks)packages/commands/src/query/tokens/index.ts(1 hunks)packages/commands/src/query/tokens/list.ts(1 hunks)packages/commands/src/query/tokens/show.ts(2 hunks)packages/commands/src/solana/call.ts(1 hunks)packages/commands/src/solana/depositAndCall.ts(1 hunks)packages/commands/src/solana/index.ts(1 hunks)packages/commands/src/sui/index.ts(1 hunks)packages/commands/src/ton/deposit.ts(1 hunks)packages/commands/src/ton/depositAndCall.ts(1 hunks)packages/commands/src/ton/index.ts(1 hunks)packages/commands/src/zetachain/call.ts(1 hunks)packages/commands/src/zetachain/index.ts(1 hunks)packages/commands/src/zetachain/withdraw.ts(1 hunks)packages/commands/src/zetachain/withdrawAndCall.ts(1 hunks)utils/zetachain.command.helpers.ts(2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: hernan-clich
PR: zeta-chain/toolkit#329
File: utils/evm.command.helpers.ts:21-38
Timestamp: 2025-05-16T20:59:05.735Z
Learning: In the ZetaChain toolkit, base schemas like `baseEvmDepositOptionsSchema` are intentionally kept flexible, with mutual exclusivity refinements like name/privateKey validation happening in the specific command implementations that extend the base schema, rather than in the base schema itself.
Learnt from: fadeev
PR: zeta-chain/toolkit#346
File: packages/commands/src/ton/depositAndCall.ts:0-0
Timestamp: 2025-06-13T15:33:54.781Z
Learning: fadeev prefers responses in English.
Learnt from: fadeev
PR: zeta-chain/toolkit#346
File: packages/commands/src/ton/deposit.ts:0-0
Timestamp: 2025-06-13T15:32:09.225Z
Learning: User fadeev prefers that responses be in English; avoid replying in Russian in future interactions.
📚 Learning: 2025-05-16T20:59:05.735Z
Learnt from: hernan-clich
PR: zeta-chain/toolkit#329
File: utils/evm.command.helpers.ts:21-38
Timestamp: 2025-05-16T20:59:05.735Z
Learning: In the ZetaChain toolkit, base schemas like `baseEvmDepositOptionsSchema` are intentionally kept flexible, with mutual exclusivity refinements like name/privateKey validation happening in the specific command implementations that extend the base schema, rather than in the base schema itself.
Applied to files:
packages/commands/src/evm/depositAndCall.tspackages/commands/src/ton/deposit.tspackages/commands/src/evm/deposit.tspackages/commands/src/evm/index.ts
🧬 Code graph analysis (10)
packages/commands/src/evm/depositAndCall.ts (2)
packages/commands/src/solana/depositAndCall.ts (1)
depositAndCallCommand(69-100)packages/commands/src/ton/depositAndCall.ts (1)
depositAndCallCommand(76-100)
packages/commands/src/query/chains/list.ts (1)
src/constants/api.ts (1)
DEFAULT_API_URL(1-2)
packages/commands/src/zetachain/withdrawAndCall.ts (1)
utils/zetachain.command.helpers.ts (1)
addCommonZetachainCommandOptions(191-263)
packages/commands/src/query/fees.ts (1)
src/constants/api.ts (2)
DEFAULT_API_URL(1-2)DEFAULT_EVM_RPC_URL(3-4)
packages/commands/src/evm/deposit.ts (5)
packages/commands/src/ton/deposit.ts (1)
depositCommand(71-80)packages/commands/src/bitcoin/inscription/deposit.ts (1)
depositCommand(145-159)packages/commands/src/bitcoin/memo/deposit.ts (1)
depositCommand(80-90)packages/commands/src/sui/deposit.ts (1)
depositCommand(39-44)packages/commands/src/solana/deposit.ts (1)
depositCommand(62-80)
packages/commands/src/query/tokens/list.ts (1)
src/constants/api.ts (1)
DEFAULT_API_URL(1-2)
packages/commands/src/evm/call.ts (3)
packages/commands/src/solana/call.ts (1)
callCommand(64-84)packages/commands/src/bitcoin/inscription/call.ts (1)
callCommand(163-178)packages/commands/src/bitcoin/memo/call.ts (1)
callCommand(85-92)
utils/zetachain.command.helpers.ts (1)
types/shared.constants.ts (1)
DEFAULT_ACCOUNT_NAME(1-1)
packages/commands/src/zetachain/call.ts (1)
utils/zetachain.command.helpers.ts (1)
addCommonZetachainCommandOptions(191-263)
packages/commands/src/accounts/import.ts (1)
types/accounts.types.ts (1)
AvailableAccountTypes(14-20)
🔇 Additional comments (17)
packages/commands/src/solana/call.ts (1)
65-66: LGTM — clear and consistent phrasingThe summary/description pair reads well and matches the surrounding Solana command wording.
packages/commands/src/accounts/show.ts (1)
42-45: LGTM: clear, user-focused description.Reads well and matches the command’s behavior.
packages/commands/src/query/cctx.ts (1)
252-255: LGTM: concise and informative help text.The new summary/description clearly sets expectations without overloading the user.
packages/commands/src/query/fees.ts (3)
80-81: LGTM: concise summary and description read wellClear and consistent with the rest of the query command set.
89-92: LGTM: gas-limit help text is clearThe option now communicates its purpose without ambiguity.
94-94: Standardized JSON phrasing“Output in JSON format” aligns with the rest of the CLI. Good.
packages/commands/src/accounts/import.ts (2)
34-34: LGTM: summary reads well
41-42: LGTM: “Chain type” matches wording used across account commandspackages/commands/src/query/chains/show.ts (2)
335-338: LGTM: summary/description are specific and helpfulGood mention of testnet/mainnet and scripting-friendly field output.
358-358: LGTM: JSON wording standardizedpackages/commands/src/query/tokens/show.ts (1)
165-165: LGTM: standardized JSON phrasingConsistent with other commands.
packages/commands/src/evm/deposit.ts (1)
98-107: Validation + action wiring looks goodGood use of
validateAndParseSchema(..., { exitOnError: true })before invokingmain. This aligns with patterns in other chains.packages/commands/src/ton/index.ts (1)
7-10: TON command help improvement looks goodClearer summary/description; reads well in
--help.packages/commands/src/zetachain/withdraw.ts (1)
88-91: Helpful, user-focused descriptionNice enhancement—explains behavior (no contract call) and available knobs (receiver, amount, advanced options).
packages/commands/src/program.ts (1)
17-19: LGTM: helpful top-level descriptionAdds a clear, concise description for the root command without affecting behavior.
packages/commands/src/zetachain/index.ts (1)
8-11: LGTM — concise and informative summary/description.The copy clearly communicates cross-chain capabilities and aligns with the command surface.
packages/commands/src/zetachain/call.ts (1)
134-134: Two-step initialization reads clearer and aligns with common patternSplitting construction from configuration improves readability and matches patterns used elsewhere. Looks good.
| new Option("--type <type>", "Chain type").choices(AvailableAccountTypes) | ||
| ) |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Copy looks good; ensure “Chain type” phrasing is consistent repo-wide
This aligns with the broader shift from “Account type” → “Chain type.” Quick scan recommended to ensure no remnants remain in other commands.
Expected: No matches.
---
🏁 Script executed:
```shell
#!/bin/bash
# Check for lingering "Account type" labels in options across the repo
rg -n -C2 -P 'Option\("--type\s*<type>",\s*"Account type"\)'
Length of output: 424
Ensure “Chain type” phrasing is consistent across all account commands
We’ve detected one remaining instance of the old “Account type” label that needs updating for consistency.
• packages/commands/src/accounts/show.ts, line 47
Change
new Option("--type <type>", "Account type").choices(AvailableAccountTypes)to
new Option("--type <type>", "Chain type").choices(AvailableAccountTypes)🤖 Prompt for AI Agents
In packages/commands/src/accounts/create.ts around lines 40-41 the Option
description already uses "Chain type"; ensure consistency by updating
packages/commands/src/accounts/show.ts (around line 47) to replace the outdated
"Account type" description with "Chain type" on the new Option("--type <type>",
...) so both commands use the same phrasing and AvailableAccountTypes choices.
| .description( | ||
| "Queries the real-time status of a cross-chain transaction by its inbound transaction hash. You can control polling frequency, timeout, and target RPC endpoint." | ||
| ) | ||
| .requiredOption("-h, --hash <hash>", "Inbound transaction hash") |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Potential conflict: short flag “-h” is commonly reserved for help in Commander.
Commander defaults the help option to “-h, --help”. Reusing “-h” for “--hash” can shadow/override help or cause conflicts depending on version/config. Suggest changing the short flag (e.g., “-i, --hash” or drop the short flag) in a follow-up PR to avoid a breaking CLI change here.
Run this repo-scope check to find any other places where “-h” is used for non-help and whether help flags are customized:
🏁 Script executed:
#!/usr/bin/env bash
# Find custom options using -h short flag
rg -nP --type=ts -C2 'requiredOption\(\s*["'\'']-h[,\s]'
# Check for help option customizations
rg -nP --type=ts -C2 '\.helpOption\('Length of output: 608
Avoid using “-h” for hash flag—it conflicts with the default help shortcut
Our repository-wide grep shows that the only occurrence of a custom -h flag is here, and there is no reconfiguration of the built-in help option—Commander will still reserve -h for --help, so the new -h, --hash binding will override or break the help command:
• packages/commands/src/query/cctx.ts:256
.requiredOption("-h, --hash <hash>", "Inbound transaction hash")
This is a breaking CLI change. Please update the short flag for the hash parameter (for example, -x, --hash or drop the short form) in a follow-up PR.
🤖 Prompt for AI Agents
In packages/commands/src/query/cctx.ts around line 256, the option currently
uses the short flag `-h` which conflicts with Commander’s built-in help; replace
the short flag with a non-conflicting letter (for example `-x, --hash <hash>`)
or remove the short form entirely so the option becomes `--hash <hash>`, and
update any nearby usage or help text/comments to match the new flag.
| "--abort-address <address>", | ||
| "Address to receive tokens if transaction isaborted", | ||
| ZeroAddress | ||
| ) |
There was a problem hiding this comment.
Fix user-facing typo: “isaborted” → “is aborted”
This appears in CLI help and should be corrected.
.option(
"--abort-address <address>",
- "Address to receive tokens if transaction isaborted",
+ "Address to receive tokens if the transaction is aborted",
ZeroAddress
)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "--abort-address <address>", | |
| "Address to receive tokens if transaction isaborted", | |
| ZeroAddress | |
| ) | |
| .option( | |
| "--abort-address <address>", | |
| "Address to receive tokens if the transaction is aborted", | |
| ZeroAddress | |
| ) |
🤖 Prompt for AI Agents
In utils/zetachain.command.helpers.ts around lines 223 to 226, the CLI help text
contains a typo "isaborted"; update the string to "is aborted" so the help
message reads "Address to receive tokens if transaction is aborted". Ensure
spacing and punctuation match surrounding entries and run any linter/formatter
if required.
| "--on-revert-gas-limit <limit>", | ||
| "Gas limit for the revert transaction", | ||
| "1000000" | ||
| ) |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Default gas limits are inconsistent with schema defaults
CLI option defaults here are “1000000”, but baseZetachainOptionsSchema sets defaults to “7000000” for onRevertGasLimit, txOptionsGasLimit, and callOptionsGasLimit. Commander defaults override schema defaults, so users will get 1,000,000 even though the schema advertises 7,000,000. Please align to avoid surprising behavior.
If “7,000,000” is the intended default, update the CLI defaults:
.option(
"--on-revert-gas-limit <limit>",
"Gas limit for the revert transaction",
- "1000000"
+ "7000000"
)
.option(
"--tx-options-gas-limit <limit>",
"Gas limit for the transaction",
- "1000000"
+ "7000000"
)
.option(
"--call-options-gas-limit <limit>",
"Gas limit for the contract call on the connected chain",
- "1000000"
+ "7000000"
)If “1,000,000” is the new standard, please also update the baseZetachainOptionsSchema defaults to match.
Also applies to: 243-246, 253-256
🏁 Script executed:
#!/bin/bash
# Locate the schema definition to verify default gas limits
rg -n "baseZetachainOptionsSchema" -C3
# Inspect CLI helper around the on-revert-gas-limit defaults
sed -n '220,260p' utils/zetachain.command.helpers.tsLength of output: 5424
🏁 Script executed:
#!/bin/bash
# Verify schema for onRevertGasLimit default
rg -n "onRevertGasLimit" -C3 utils/zetachain.command.helpers.ts
# Verify schema for txOptionsGasLimit default
rg -n "txOptionsGasLimit" -C3 utils/zetachain.command.helpers.ts
# List occurrences of numericStringSchema.default("7000000")
rg -n 'numericStringSchema\.default\("7000000"\)' -C3 utils/zetachain.command.helpers.tsLength of output: 2333
Align CLI option defaults with schema defaults
The CLI helpers in utils/zetachain.command.helpers.ts are currently defaulting gas limits to "1000000", but the baseZetachainOptionsSchema in the same file sets all three limits to "7000000". Commander’s .option() defaults override the schema, so users invoking the CLI without flags will receive 1 million gas rather than the 7 million advertised by the schema.
Please reconcile these defaults to avoid confusing behavior:
• Locations to update in utils/zetachain.command.helpers.ts:
- Lines ~233–236:
.option("--on-revert-gas-limit <limit>", …, "1000000") - Lines ~241–244:
.option("--tx-options-gas-limit <limit>", …, "1000000") - Lines ~249–252:
.option("--call-options-gas-limit <limit>", …, "1000000")
• Schema defaults in the same file (lines 22–44):
callOptionsGasLimit: numericStringSchema.default("7000000"),
onRevertGasLimit: numericStringSchema.default("7000000"),
txOptionsGasLimit: numericStringSchema.default("7000000"),If the intended default is 7 million, update the CLI as follows:
.option(
"--on-revert-gas-limit <limit>",
"Gas limit for the revert transaction",
- "1000000"
+ "7000000"
)
.option(
"--tx-options-gas-limit <limit>",
"Gas limit for the transaction",
- "1000000"
+ "7000000"
)
.option(
"--call-options-gas-limit <limit>",
"Gas limit for the contract call on the connected chain",
- "1000000"
+ "7000000"
)If, instead, 1 000 000 is the new standard, please adjust the schema defaults in baseZetachainOptionsSchema to "1000000" so both layers remain in sync.
🤖 Prompt for AI Agents
In utils/zetachain.command.helpers.ts around lines 233–236 (and similarly
~241–244 and ~249–252), the Commander .option() defaults are set to "1000000"
while baseZetachainOptionsSchema (lines ~22–44) sets those three gas limits to
"7000000", causing inconsistent defaults; reconcile them by choosing the
intended default and making both places match—either change the three
.option(..., "1000000") calls to "7000000" if 7M is intended, or update the
schema defaults for callOptionsGasLimit, onRevertGasLimit, and txOptionsGasLimit
to "1000000" if 1M is intended, and ensure the values are identical strings in
both the CLI helpers and the schema.
Summary by CodeRabbit
New Features
Documentation