Favorite/Best Dev Stack?

About to take the plunge, starting from 0, with Contract development. I’m on a MacBook Pro and super-used to VSCode and the command line for all development-related things. Since this is a brand new endeavor, I’d love to hear what’s worked for you and what hasn’t, in terms of software stack. Of course, I’ve been doing my own research and there are a few options out there, but I figured passionate, knowledgable users with real-world experience would be a great influence here.

What tools should I use to get up and running and hacking away with OpenZeppelin in both the shortest amount of time, and doing thing the “right” way, so when it’s time to deploy for real, it’s not a totally new learning curve?

3 Likes

Hi @EvilJordan,

I suggest having a look through this thread, I just updated what I am using:

macOS and VSCode are already decided then :smile:.

I recommend @juanfranblanco’s excellent VSCode plugin: (see some VSC extension recommendations including how to configure for OpenZeppelin). It also allows formatting (which is awesome and I use all the time).

I would recommend using nvm if you aren’t already, to easily change node versions. Node 14 is out but I use node 10. There may be issues with dependencies using node 13 and beyond.

For local development, ganache-cli (you could try the GUI version, though I haven’t properly played with it).

The next choice is tools for developing/testing smart contracts.

I started with Truffle in 2017, I used Embark briefly in early 2019, I :heart: the OpenZeppelin CLI and use this wherever possible, I only started playing with buidler this week.

The other thing to consider is web3.js vs ethers.js. I have mostly used web3.js. Though ethers.js users I have come across are fans.

This weeks Annotated edition of May 3 Week in Ethereum News had the following:

It feels like a very undercommented trend how most devs now tell me that their stack is Buidler + Waffle + ethers, and increasingly Typescript as well. Of course, dev tool stacks are perpetually in flux, but this seems to be the stack du jour.

My recommendation would be to use OpenZeppelin CLI, along with OpenZeppelin Test Environment for testing. (see OpenZeppelin Learn guides). I am naturally biased :smile:, but believe this is a great place to get started.

It isn’t much effort to swap to Truffle if you need. If you are creating upgradeable smart contracts, then OpenZeppelin CLI is the best choice.

You can also use oz-console to interact with OpenZeppelin CLI deployed contracts using ethers.js.

2 Likes

Amaze. Thank you! :hugs:

1 Like

Me and our team at Kyber switched to buidler EVM and we found it far better then ganache

one of the main features is logging out of your contract. which works even if the Tx is reverted.
this is soooo helpful. I can’t event start saying how much debugging hours it saved us.

3 Likes

+1 to Buidler. It’s fast, shows stack traces, and even has a Solidity console logger!

I managed to get it to play nicely with OZ SDK as well, so now I have fantastic test tools and deployment tools.

I would love to see a Buidler plugin that allows OZ to use it’s network configuration, or vice versa. That’s the only place I haven’t been able to keep very DRY.

2 Likes

Would you be willing to post a quick writeup on how you managed that?

1 Like

Have a look at the version-3 branch in the PoolTogether Contracts repository on Github.

It was fairly straightforward. The only problem is that the evil twin package of the OpenZeppelin contracts hasn’t been updated to match OpenZeppelin Contracts 3.0, so I’ve had to cut and paste a few contracts.

[edit]

You can just initialize a new oz init inside of a Buidler project. If it helps, I initialized Buidler first and then called oz init to bootstrap the oz config.

2 Likes

Hi @asselstine,

Thanks for sharing your development setup :pray:

The OpenZeppelin Contracts Ethereum Package 3.0 should be a week or so away.
(see: https://github.com/OpenZeppelin/openzeppelin-contracts-ethereum-package/issues/79)

Please note: storage layout changes likely means that contracts can’t be upgraded from 2.5 to 3.0.

1 Like

Thank you @abcoathup and @asselstine! I’ve been running through all the tutorials and am on my way!

The only piece I’m confused about when using OpenZeppelin and Buidler, is how the CLIs work together.

Buidler has the awesome console.loging methods, but OZ makes it super-easy to upgrade and query.

I’m assuming a good process is to test/debug with Buidler, compile and deploy with either Buidler or OZ, and then use OZ for chain interaction/upgrade deployments?

If so, I can completely avoid the use of ganache/truffle since Buidler has an EVM built-in, right?

1 Like

Hi @EvilJordan,

I haven’t used buidler in anger, so can’t add much to this. I am not sure how the two CLIs interact, I have only used OpenZeppelin CLI by itself or with Truffle.

If you are creating upgradeable contracts then the OpenZeppelin CLI is best for deployment. You can test your logic contracts using any test library or test framework. (Though OpenZeppelin Test Environment is great)

If you are creating upgradeable contracts then the OpenZeppelin CLI is best for deployment.

Yes- I second this. And even if you’re not deploying upgradeable contracts, you can easily deploy minimal proxies which saves tremendous amounts of gas.

The only thing I felt missing from the OZ deploy process was a convenient migration tool. If it helps, you can have a look at our migration file.

I’ve been using Buidler for testing, and it’s been great. Solidity stack traces and console logging have dramatically improved the test experience. For deployment, OZ is the way to go.

1 Like

The other thing to consider is web3.js vs ethers.js. I have mostly used web3.js. Though ethers.js users I have come across are fans.

+1 for ethers.js - human readable ABIs - Boom!

1 Like

Hi @asselstine,

OpenZeppelin Contracts Ethereum Package v3.0 has been released.

1 Like