ci: generate contract addresses #380
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #380 +/- ##
=======================================
Coverage 84.23% 84.23%
=======================================
Files 8 8
Lines 387 387
Branches 121 121
=======================================
Hits 326 326
Misses 61 61 ☔ View full report in Codecov by Sentry. |
fadeev
requested review from
andresaiello,
brewmaster012,
lumtis,
CharlieMc0,
skosito and
fbac
as code owners
📝 Walkthrough📝 WalkthroughWalkthroughThis pull request introduces several new files and modifications to set up a Hardhat project environment. It includes a new Hardhat configuration file, Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
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: 9
🧹 Outside diff range and nitpick comments (12)
v2/lib/index.ts (1)
1-1: Consider adding a brief explanatory comment.To improve maintainability, consider adding a brief comment at the top of the file explaining its purpose and the nature of the exported data. This can help other developers quickly understand the role of this file in the project.
Here's a suggested comment you could add at the beginning of the file:
/** * Central export point for address-related data and types. * Includes mainnet and testnet addresses, as well as address utility functions and type definitions. */v2/scripts/generate_addresses.sh (3)
5-6: LGTM: Proper address generation for testnet and mainnet.The script correctly uses Hardhat to generate addresses for both testnet and mainnet, storing the results in appropriately named JSON files within the
./data/directory.Consider adding basic error handling to ensure the commands execute successfully:
-npx hardhat addresses --network zeta_testnet > ./data/addresses.testnet.json -npx hardhat addresses --network zeta_mainnet > ./data/addresses.mainnet.json +npx hardhat addresses --network zeta_testnet > ./data/addresses.testnet.json || { echo "Error generating testnet addresses"; exit 1; } +npx hardhat addresses --network zeta_mainnet > ./data/addresses.mainnet.json || { echo "Error generating mainnet addresses"; exit 1; }This change will cause the script to exit with an error message if either command fails, improving the script's robustness.
8-10: LGTM: Proper generation of protocol address types.The script correctly uses
ts-nodeto execute a TypeScript file for generating address types, storing the result in a TypeScript file within the./lib/directory. This approach ensures type safety in the project.Consider adding basic error handling to ensure the command executes successfully:
-npx ts-node scripts/generate_addresses_types.ts > ./lib/types.ts +npx ts-node scripts/generate_addresses_types.ts > ./lib/types.ts || { echo "Error generating address types"; exit 1; }This change will cause the script to exit with an error message if the command fails, improving the script's robustness.
1-10: Overall: Well-structured script with room for minor improvements.The script effectively accomplishes its goals of generating addresses and types for both testnet and mainnet. It uses appropriate tools and follows good practices for file organization.
Consider adding more detailed user feedback to improve the script's usability:
#!/bin/bash echo "Generating protocol addresses..." -npx hardhat addresses --network zeta_testnet > ./data/addresses.testnet.json -npx hardhat addresses --network zeta_mainnet > ./data/addresses.mainnet.json +npx hardhat addresses --network zeta_testnet > ./data/addresses.testnet.json && echo "Testnet addresses generated successfully." || { echo "Error generating testnet addresses"; exit 1; } +npx hardhat addresses --network zeta_mainnet > ./data/addresses.mainnet.json && echo "Mainnet addresses generated successfully." || { echo "Error generating mainnet addresses"; exit 1; } echo "Generating protocol addresses types..." -npx ts-node scripts/generate_addresses_types.ts > ./lib/types.ts +npx ts-node scripts/generate_addresses_types.ts > ./lib/types.ts && echo "Address types generated successfully." || { echo "Error generating address types"; exit 1; } + +echo "Address generation complete. Files created:" +echo "- ./data/addresses.testnet.json" +echo "- ./data/addresses.mainnet.json" +echo "- ./lib/types.ts"These changes will provide more detailed feedback to the user about the progress and results of the script execution.
v2/hardhat.config.ts (1)
1-4: LGTM! Consider grouping imports.The imports look good and cover all necessary modules for the Hardhat configuration. They include the Hardhat toolbox, a custom task, network configuration, and the correct type import.
Consider grouping the imports by external packages, internal modules, and types for better organization:
import "@nomicfoundation/hardhat-toolbox"; import { getHardhatConfigNetworks } from "@zetachain/networks"; import "./tasks/addresses"; import { HardhatUserConfig } from "hardhat/config";v2/tasks/addresses.mainnet.json (1)
1-16: Consider adding documentation for the address list.While the JSON structure is clear, it might be helpful to add some documentation (either in this file as a comment or in a separate README) explaining:
- The purpose of this address list
- The meaning and possible values for each field (especially the "category" field)
- How this file relates to other parts of the system (if applicable)
This would improve maintainability and make it easier for other developers to understand and use this data.
v2/lib/types.ts (3)
1-1: LGTM! Consider standardizing chain suffixes for consistency.The
ParamSymboltype definition is comprehensive and includes a wide range of cryptocurrency symbols. The naming convention is generally consistent, using uppercase letters for tokens and chains.For improved consistency, consider standardizing the use of chain suffixes for all symbols. For example:
- Change "USDC" to "USDC.ZETA" (assuming it's on the Zeta chain)
- Change "gETH" to "gETH.ZETA" (if it's specific to the Zeta chain)
This would make it clearer which chain each token belongs to and maintain a consistent format across all symbols.
2-2: LGTM! Consider adding a comment for easy updates.The
ParamChainNametype definition is well-structured and comprehensive, covering major blockchain networks and their testnets. The naming convention is consistent, using lowercase letters and underscores.To make future updates easier, consider adding a comment above the type definition explaining the naming convention and listing any potential future additions. For example:
// Chain name format: <chain>_<network> // TODO: Add new chains here as they are supported export type ParamChainName = "eth_mainnet" | "bsc_mainnet" | ...;This will help maintain consistency and make it clear where to add new chains as the project expands.
3-3: LGTM! Consider grouping related types for better readability.The
ParamTypedefinition is comprehensive and covers a wide range of blockchain-related components. The naming convention is consistent, using camelCase for multi-word types.To improve readability and organization, consider grouping related types together using comments. For example:
export type ParamType = // General types | "connector" | "erc20Custody" | "tss" | "systemContract" // Uniswap related | "uniswapV2Factory" | "uniswapV2Router02" | "uniswapV3Factory" | "uniswapV3Router" // Token related | "weth9" | "zetaToken" | "zrc20" | "zetaTokenConsumerUniV3" // Modules | "fungibleModule";This grouping will make it easier to understand the different categories of types and to add new types in the appropriate sections in the future.
v2/lib/addresses.ts (1)
8-12: Consider improving the error message for clarity.The validation logic is correct, but the error message could be more specific to help developers understand the issue quickly.
Consider updating the error message as follows:
- throw new Error("Symbol is only supported when ParamType is zrc20"); + throw new Error(`Symbol parameter is only supported when type is "zrc20". Received type: ${type}`);This change provides more context about the error condition.
v2/tasks/addresses.testnet.json (1)
1-44: Consider optimizing the "category" field.All entries have the "category" field set to "messaging". If this is expected to be constant across all entries, consider moving it to a higher level in the data structure or removing it from individual entries to reduce redundancy.
v2/tasks/addresses.ts (1)
293-294: Remove commented-out code for clarityThe calls to
fetchTSSUpdaterandfetchPauserare commented out. If these functions are no longer needed, consider removing the commented code to improve readability. If they are intended for future use, add a comment explaining when they should be re-enabled.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (39)
v2/data/addresses.mainnet.jsonis excluded by!v2/data/**v2/data/addresses.testnet.jsonis excluded by!v2/data/**v2/docs/src/contracts/Revert.sol/interface.Revertable.mdis excluded by!v2/docs/**v2/docs/src/contracts/Revert.sol/struct.RevertContext.mdis excluded by!v2/docs/**v2/docs/src/contracts/Revert.sol/struct.RevertOptions.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/ERC20Custody.sol/contract.ERC20Custody.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/GatewayEVM.sol/contract.GatewayEVM.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/ZetaConnectorBase.sol/abstract.ZetaConnectorBase.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/ZetaConnectorNative.sol/contract.ZetaConnectorNative.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/ZetaConnectorNonNative.sol/contract.ZetaConnectorNonNative.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IERC20Custody.sol/interface.IERC20Custody.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IERC20Custody.sol/interface.IERC20CustodyErrors.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IERC20Custody.sol/interface.IERC20CustodyEvents.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IGatewayEVM.sol/interface.Callable.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IGatewayEVM.sol/interface.IGatewayEVM.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IGatewayEVM.sol/interface.IGatewayEVMErrors.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IGatewayEVM.sol/interface.IGatewayEVMEvents.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IGatewayEVM.sol/struct.MessageContext.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IZetaConnector.sol/interface.IZetaConnectorEvents.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IZetaNonEthNew.sol/interface.IZetaNonEthNew.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/GatewayZEVM.sol/contract.GatewayZEVM.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/SystemContract.sol/contract.SystemContract.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/SystemContract.sol/interface.SystemContractErrors.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/ZRC20.sol/contract.ZRC20.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/ZRC20.sol/interface.ZRC20Errors.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IGatewayZEVM.sol/interface.IGatewayZEVM.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IGatewayZEVM.sol/interface.IGatewayZEVMErrors.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IGatewayZEVM.sol/interface.IGatewayZEVMEvents.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IGatewayZEVM.sol/struct.CallOptions.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/ISystem.sol/interface.ISystem.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IWZETA.sol/interface.IWETH9.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IZRC20.sol/enum.CoinType.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IZRC20.sol/interface.IZRC20.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IZRC20.sol/interface.IZRC20Metadata.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IZRC20.sol/interface.ZRC20Events.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/UniversalContract.sol/interface.UniversalContract.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/UniversalContract.sol/interface.zContract.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/UniversalContract.sol/struct.zContext.mdis excluded by!v2/docs/**v2/yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (11)
- v2/hardhat.config.ts (1 hunks)
- v2/lib/addresses.ts (1 hunks)
- v2/lib/index.ts (1 hunks)
- v2/lib/types.ts (1 hunks)
- v2/package.json (2 hunks)
- v2/scripts/generate_addresses.sh (1 hunks)
- v2/scripts/generate_addresses_types.ts (1 hunks)
- v2/tasks/addresses.mainnet.json (1 hunks)
- v2/tasks/addresses.testnet.json (1 hunks)
- v2/tasks/addresses.ts (1 hunks)
- v2/tasks/readme.md (1 hunks)
✅ Files skipped from review due to trivial changes (1)
- v2/tasks/readme.md
🧰 Additional context used
🪛 Biome
v2/scripts/generate_addresses_types.ts
[error] 21-21: isNaN is unsafe. It attempts a type coercion. Use Number.isNaN instead.
See the MDN documentation for more details.
Unsafe fix: Use Number.isNaN instead.(lint/suspicious/noGlobalIsNan)
🔇 Additional comments (21)
v2/lib/index.ts (1)
1-4: LGTM! Clean and organized exports.The file structure looks good. It provides a centralized point for exporting address-related data and types, which is a clean and maintainable approach. The order of exports is logical, with specific imports first followed by general re-exports.
v2/scripts/generate_addresses.sh (1)
1-3: LGTM: Proper script setup and user feedback.The script starts with the correct shebang for a bash script and includes a clear echo statement to inform the user about the address generation process.
v2/hardhat.config.ts (2)
13-13: LGTM!The default export of the configuration object is correct and follows the standard practice for Hardhat configuration files.
6-11: Verify Solidity version compatibility.The configuration looks good overall. It correctly sets up the networks using the ZetaChain-specific function and defines the Solidity version.
Please verify that all your dependencies and contracts are compatible with Solidity 0.8.26. This is a recent version, which is good for security but might cause issues with some libraries. Run the following script to check for potential compatibility issues:
v2/tasks/addresses.mainnet.json (3)
1-16: LGTM: JSON structure is valid and consistent.The file contains a well-structured JSON array with consistent object properties for each entry.
2-8: Verify the "messaging" category for Uniswap V2 Router.The Uniswap V2 Router address and other details are correct. However, the "messaging" category seems unusual for a Uniswap router. Could you please verify if this categorization is intentional or if it should be adjusted to better reflect the router's purpose (e.g., "defi" or "exchange")?
9-15: LGTM: Uniswap V3 Router details are correct.The Uniswap V3 Router address and other details are accurate. However, the "messaging" category is consistent with the V2 entry but still seems unusual for a Uniswap router.
Please confirm if the "messaging" category is intentional for both Uniswap router entries.
v2/lib/types.ts (1)
1-4: Overall, excellent type definitions with room for minor enhancements.The
types.tsfile provides well-structured and comprehensive type definitions for blockchain-related symbols, chain names, and parameter types. These definitions will enhance type safety and clarity in the codebase.While the current implementation is solid, consider the suggested minor improvements for consistency, readability, and future maintainability:
- Standardize chain suffixes in
ParamSymbol- Add a comment for easy updates in
ParamChainName- Group related types in
ParamTypeThese enhancements will further improve the already high-quality type definitions.
v2/lib/addresses.ts (2)
1-7: LGTM: Imports and function signature are well-defined.The imports are appropriate, and the function signature is well-typed using custom types, which enhances type safety and code readability.
1-25: Overall assessment: Well-structured function with room for minor improvements.The
getAddressfunction is well-implemented and handles the required logic correctly. It effectively retrieves blockchain addresses based on the provided parameters and handles different cases appropriately.Key strengths:
- Clear separation of logic for different cases.
- Use of TypeScript for enhanced type safety in function parameters.
- Proper error handling for invalid parameter combinations.
Suggested improvements:
- Enhance type safety by defining and using a specific interface for network objects.
- Improve error messaging for better developer experience.
- Consider adding type annotations to the return statement for clarity.
These improvements will further enhance the robustness and maintainability of the code.
v2/tasks/addresses.testnet.json (2)
1-44: LGTM: JSON structure is valid and consistent.The file structure follows proper JSON syntax, with a single array containing multiple address objects. Each object has a consistent set of fields, making it easy to parse and use programmatically.
1-44: Verify the correctness of addresses and their associations.While the data structure and format appear correct, it's crucial to ensure that:
- Each address is correctly associated with its specified chain and type.
- The addresses are up-to-date and match the intended contracts on each testnet.
Consider adding a comment or documentation explaining the source or method of generating these addresses to facilitate future updates and verifications.
To assist in verification, you can use the following script to check the contract code existence for each address:
This script will help verify the existence of contract code at each address on its respective network.
v2/scripts/generate_addresses_types.ts (5)
1-6: LGTM: Imports and type assertions are correctly implemented.The imports and type assertions are properly set up to handle the JSON data from mainnet and testnet address files. This ensures type safety when working with the imported data throughout the script.
8-11: LGTM:extractUniqueValuesfunction is well-implemented.The
extractUniqueValuesfunction efficiently extracts unique values for a given key from an array of objects. It handles potential undefined values, ensures string conversion for consistency, and uses a Set for efficient uniqueness checking.
32-42: LGTM:toCamelCasefunction is well-implemented.The
toCamelCasefunction effectively converts strings with underscores to camelCase format. It provides flexibility with the option to capitalize the first letter, which is useful for generating different types of identifiers. The implementation is clear, concise, and handles edge cases well.
44-46: LGTM: Script execution is correctly set up.The script execution part is well-structured. It defines an array of relevant keys ("symbol", "chain_name", "type") for address-related types and correctly calls the
generateTypesForKeysfunction with these keys. This setup ensures that the necessary type definitions are generated for the project's needs.
1-46: Overall, the implementation is solid with one minor improvement suggested.This script effectively generates TypeScript type definitions based on address data from mainnet and testnet. The code is well-structured, with clear and concise functions that handle the extraction of unique values, type generation, and string formatting.
Key points:
- Imports and type assertions are correctly implemented.
- The
extractUniqueValuesfunction efficiently handles data extraction and uniqueness.- The
generateTypesForKeysfunction effectively generates type definitions, with a minor suggestion to useNumber.isNaNfor safer numeric checking.- The
toCamelCasefunction provides flexible string formatting.- The script execution is set up correctly with relevant keys.
The only suggested improvement is to replace
isNaNwithNumber.isNaNin thegenerateTypesForKeysfunction for safer numeric checking. Otherwise, the implementation is robust and achieves its intended purpose.🧰 Tools
🪛 Biome
[error] 21-21: isNaN is unsafe. It attempts a type coercion. Use Number.isNaN instead.
See the MDN documentation for more details.
Unsafe fix: Use Number.isNaN instead.(lint/suspicious/noGlobalIsNan)
v2/package.json (4)
35-35: LGTM: Enhanced testing and utility dependencies.The addition of Chai, Mocha types, Axios, Lodash, and solidity-coverage enhances the project's testing capabilities and development efficiency.
To ensure the security of these new dependencies, please run an audit:
#!/bin/bash # Description: Audit new dependencies for potential vulnerabilities yarn audit --groups dependencies devDependenciesAlso applies to: 37-37, 42-43, 49-50
63-63: LGTM: Addition of types field for improved TypeScript support.The addition of the "types" field pointing to "./dist/lib/index.d.ts" improves TypeScript support for users of this package.
Please ensure that the TypeScript declaration file is being generated correctly. Run the following command to verify:
#!/bin/bash # Description: Verify TypeScript declaration file generation yarn build || yarn compile # Use the appropriate build command ls -l ./dist/lib/index.d.ts
61-61: Verify the ethers library downgrade.The ethers library has been downgraded from version 6.13.1 to 5.6.8. This is a significant change that may impact compatibility with other dependencies or existing code.
Please provide justification for this downgrade and confirm that it doesn't introduce any breaking changes. Additionally, run the following command to check for any compatibility issues:
24-31: LGTM: Comprehensive addition of Hardhat dependencies.The addition of Hardhat and its related packages is a positive change that aligns with the PR objectives. It provides a robust development environment for Ethereum smart contracts.
Please ensure all newly added Hardhat packages are compatible with each other and with the project's existing dependencies. Run the following command to check for any potential conflicts:
Also applies to: 34-34
|
Will be adding Solana gateway program address in this PR. |
There was a problem hiding this comment.
Actionable comments posted: 8
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (37)
v2/data/addresses.testnet.jsonis excluded by!v2/data/**v2/docs/src/contracts/Revert.sol/interface.Revertable.mdis excluded by!v2/docs/**v2/docs/src/contracts/Revert.sol/struct.RevertContext.mdis excluded by!v2/docs/**v2/docs/src/contracts/Revert.sol/struct.RevertOptions.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/ERC20Custody.sol/contract.ERC20Custody.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/GatewayEVM.sol/contract.GatewayEVM.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/ZetaConnectorBase.sol/abstract.ZetaConnectorBase.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/ZetaConnectorNative.sol/contract.ZetaConnectorNative.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/ZetaConnectorNonNative.sol/contract.ZetaConnectorNonNative.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IERC20Custody.sol/interface.IERC20Custody.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IERC20Custody.sol/interface.IERC20CustodyErrors.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IERC20Custody.sol/interface.IERC20CustodyEvents.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IGatewayEVM.sol/interface.Callable.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IGatewayEVM.sol/interface.IGatewayEVM.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IGatewayEVM.sol/interface.IGatewayEVMErrors.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IGatewayEVM.sol/interface.IGatewayEVMEvents.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IGatewayEVM.sol/struct.MessageContext.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IZetaConnector.sol/interface.IZetaConnectorEvents.mdis excluded by!v2/docs/**v2/docs/src/contracts/evm/interfaces/IZetaNonEthNew.sol/interface.IZetaNonEthNew.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/GatewayZEVM.sol/contract.GatewayZEVM.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/SystemContract.sol/contract.SystemContract.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/SystemContract.sol/interface.SystemContractErrors.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/ZRC20.sol/contract.ZRC20.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/ZRC20.sol/interface.ZRC20Errors.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IGatewayZEVM.sol/interface.IGatewayZEVM.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IGatewayZEVM.sol/interface.IGatewayZEVMErrors.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IGatewayZEVM.sol/interface.IGatewayZEVMEvents.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IGatewayZEVM.sol/struct.CallOptions.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/ISystem.sol/interface.ISystem.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IWZETA.sol/interface.IWETH9.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IZRC20.sol/enum.CoinType.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IZRC20.sol/interface.IZRC20.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IZRC20.sol/interface.IZRC20Metadata.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/IZRC20.sol/interface.ZRC20Events.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/UniversalContract.sol/interface.UniversalContract.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/UniversalContract.sol/interface.zContract.mdis excluded by!v2/docs/**v2/docs/src/contracts/zevm/interfaces/UniversalContract.sol/struct.zContext.mdis excluded by!v2/docs/**
📒 Files selected for processing (4)
- v2/lib/types.ts (1 hunks)
- v2/package.json (2 hunks)
- v2/tasks/addresses.testnet.json (1 hunks)
- v2/tasks/addresses.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- v2/lib/types.ts
- v2/tasks/addresses.testnet.json
🧰 Additional context used
🔇 Additional comments (4)
v2/package.json (2)
63-63: LGTM: Types field added for better TypeScript support.The addition of the "types" field pointing to "./dist/lib/index.d.ts" is a good practice for TypeScript projects. It helps IDEs and other tools locate type definitions, improving developer experience and type checking in projects that depend on this package.
To ensure the correctness of the specified path, please run the following check:
#!/bin/bash # Check if the types file exists at the specified path if [ -f "./dist/lib/index.d.ts" ]; then echo "Types file exists at the specified path." else echo "Warning: Types file not found at ./dist/lib/index.d.ts. Please verify the path is correct after running the build process." fi # Check if the types file is generated during the build process if grep -q "tsc" package.json; then echo "TypeScript compilation is part of the build process, which should generate the types file." else echo "Warning: TypeScript compilation (tsc) not found in package.json scripts. Ensure the types file is being generated correctly." fi
18-18: LGTM: Address generation script added to the build process.The addition of
./scripts/generate_addresses.shto the "generate" script aligns with the PR objective of moving the contract address generation process to v2. The placement of this step in the build process seems appropriate.To ensure the new script is functioning as expected, please run the following command:
v2/tasks/addresses.ts (2)
312-312: LGTM: Task registrationThe task registration looks correct and follows the Hardhat task creation pattern.
14-14:⚠️ Potential issueRemove unnecessary global declaration of 'hre'
The global declaration
declare const hre: any;is unnecessary ashreis provided as an argument to themainfunction. Remove this line to improve code clarity and prevent potential issues with global variables.
|
@fadeev ready to be merged after conflicts are resolved |
Co-authored-by: Denis Fadeev <[email protected]>
Summary by CodeRabbit
New Features
Bug Fixes
Documentation