[Sunsetting] contractkit #10222
-
Hello Celo devs 👋 With the recent efforts from everyone at clabs to make CELO as eth-tooling-compatible as possible, it became clear that we should strive to support the existing ecosystem rather that create our own libraries. That’s why contractkit is in the process of being deprecated for public usage. While our internal tools still rely on its existence, we will stop supporting the library on public channels and will slowly migrate away from using it ourselves. If you are using Contractkit at the moment and don’t know how to migrate to ethers, web3 or viem, please contact us via Github Discussions . If you have a particularly sensitive issue please reach out to [email protected]. The contractkit code within the celo-monorepo will not be removed and it is possible that updates keep being pushed to npm. However I must emphasise that no support will be provided regarding its usage. [Copied from the forum post]. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
Hi. Just to double check. |
Beta Was this translation helpful? Give feedback.
-
Amendment noticeTLDR
More detailsRecently we pledged to achieve “deep alignment with the Ethereum community” in the Celo 2.0 roadmap. In an effort to move towards this goal, we (the cLabs developer tooling team) have been looking for ways to facilitate usage of Ethereum-compatible developer tools (such as EthersJS, viem and web3js), while continuing to provide access to Celo’s unique features (such as the ability to pay for gas with custom tokens and Celo’s diverse set of core contracts). We often hear that bundle sizes matter (in particular for mobile developers), because they increase the time and bandwidth required to install your applications. We also know that contractkit is a large dependency (currently 2.93 MB) and have been trying our best to whittle down its size for a while. In comparison, the recently published client libraries with Celo support advertise bundle sizes as small as 27kB. In an effort to improve your developer experience, we have been investigating the value/cost of contractkit in its current form and have been considering moving core contract wrappers (like accounts, governance, lockedGold, stableToken, etc) from contractkit into their own smaller package. We documented a proof of concept in this pull request: PoC: Move Generated Typescript Web3 Core Contracts to their own package #9912. We also want to minimize unnecessary changes for developers who are happy with contractkit in its current format, while balancing that with ensuring our team can minimize maintenance work across developer tools and focus on providing access to Celo’s unique features We would love to understand the many ways you use contractkit to ensure we can satisfy your needs while improving the overall developer experience. To date, we successfully collected feedback at the Wallet and Dapp Council, but have been struggling to hear from more contractkit users. Next stepsIf you are a contractkit user today, we would love to hear from you (!). We’d love to learn more about how you use contractkit and specifically what problems it solves for you. 👉 We invite contractkit users to comment on this Github discussion or reach out via [email protected]. You can also schedule a call if you would prefer speaking in-person. Thank you very much! The cLabs developer tooling team (@aaronmgdr, @dckesler, @nicolasbrugneaux, and @0xarthurxyz) |
Beta Was this translation helpful? Give feedback.
Amendment notice
TLDR
More details
Recently we pledged to achieve “deep alignment with the Ethereum community” in the Celo 2.0 roadmap. In an effort to move towards this goal, we (the cLabs developer tooling team) have been looking for ways to facilitate usage of Ethereum-compatible developer tools (such as EthersJS, viem and web3js), while continuing to provide access to Celo’s unique features (such as the ability to p…