About four months ago, I switched to Hardhat from Truffle. This cool new kid on the block drastically improved my coding experience. So today I want to share it with my fellow Solidity developers.

In this post, I will walk you through the initial set-up, compilation, testing, debugging, and finally deployment.

At the end of this post, you will be able understand how to deploy an NFT contract to the local network with Hardhat.

The goal of this post is to make you familiar with Hardhat. I won’t talk about how to write a test or Solidity syntax. However, you should be able to follow along without any Solidity knowledge if you know how to write JavaScript.

See this repo for the code.

How to Set Up the Project

Let’s start an npm project first:

npm init --yes

Then install the Hardhat package:

npm install --save-dev hardhat

Cool! Now you are ready to create a new Hardhat project:

npx hardhat

Choose Create an empty hardhat.config.js:

This will create hardhat.config.js in your root directory with the solidity compiler version specified:

/**
 * @type import('Hardhat/config').HardhatUserConfig
 */
module.exports = {
  solidity: "0.7.3",
};

How to Write and Compile the Contract

All right, we will start writing a simple contract and then we'll compile it.

Make a new Solidity file within a new contracts directory:

 mkdir contracts && cd contracts && touch MyCryptoLions.sol

We'll use the open-zeppelin package to write our NFT contract. So first, install the open-zeppelin package:

npm install --save-dev @openzeppelin/contracts

Here is the contract code we will be compiling:

pragma solidity ^0.7.3;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract MyCryptoLions is ERC721 {
    constructor(string memory name, string memory symbol)
        ERC721(name, symbol)
    {}
}

The first thing you need to do in any solidity file is to declare the compiler version. Then we can import the ERC721 contract (NFT contract) from open-zeppelin just like you do in JavaScript.

Solidity is a contract-oriented language. Just like an object-oriented language, contracts can have members such as functions and variables. In our code, we have only the constructor, which will be called when we deploy our contract.

Our contract inherits the ERC721 and then passes the name and symbol arguments which are going to be passed to the ERC721 contract. They literally decide the name and symbol of your NFT token.

We will pass whatever values we want to name and symbol at the point of deployment.

To compile it, run:

npx hardhat compile

You might get some warnings but we'll ignore them to keep things simple. You should see Compilation finished successfully at the bottom.

You should also notice that the /arfifacts and /cache directories were generated. You don’t have to worry about them for this post, but it’s good to keep in mind that you can use abi in the artifacts if you want to interact with the contract when you build the frontend.

How to Test the Contract

Since smart contracts are mostly financial applications – and they're also hard to change – testing is critical.

We will use some packages for testing. Install with the command below:

npm install --save-dev @nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers ethers

ethereum-waffle is a testing framework for smart contracts. chai is an assertion library. We'll write tests in waffle using Mocha alongside Chai. ethers.js is a JavaScript SDK for interacting with the Ethereum blockchain. The other two packages are plugins for Hardhat.

Now, let’s make a new directory test in the root directory and make a new file called test.js in it:

mkdir test && cd test && touch test.js

Make sure you require @nomiclabs/hardhat-ethers in the hardhat.config.js to make it available everywhere:

require("@nomiclabs/hardhat-ethers");

Here is a simple test:

const { expect } = require("chai");

describe("MyCryptoLions", function () {
  it("Should return the right name and symbol", async function () {
    const MyCryptoLions = await hre.ethers.getContractFactory("MyCryptoLions");
    const myCryptoLions = await MyCryptoLions.deploy("MyCryptoLions", "MCL");

    await myCryptoLions.deployed();
    expect(await myCryptoLions.name()).to.equal("MyCryptoLions");
    expect(await myCryptoLions.symbol()).to.equal("MCL");
  });
});

This code deploys our contract to the local Hardhat network and then checks if the name and symbol values are what we expect.

Run the test:

Awesome, it passed the test!

How to Use console.log() in Hardhat

Now here is the coolest thing you can do with Hardhat. You can use console.log() just like you do in JavaScript, which was not possible before. console.log() alone is more than enough reason to switch to Hardhat.

Let’s go back to your solidity file and use console.log().

pragma solidity ^0.7.3;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "hardhat/console.sol";

contract MyCryptoLions is ERC721 {
    constructor(string memory name, string memory symbol) ERC721(name, symbol) {
        console.log("name", name);
        console.log("symbol", symbol);
        console.log("msg.sender", msg.sender); //msg.sender is the address that initially deploys a contract
    }
}

And run the test again with npx hardhat test. Then the command will compile the contract again, and then run the test. You should be able to see some values logged from the contract.

This makes debugging a lot easier for you.

One caveat is that it supports only these data types:

• uint
• string
• bool
• address

But other than that, you can use it as if you are writing JavaScript.

How to Deploy the Contract

All right! Now let’s deploy our contract. We can deploy our contract to one of the testing networks, the Mainnet, or even a mirrored version of the Mainnet in local.

But in this post, we will deploy to the local in-memory instance of the Hardhat Network to keep things simple. This network is run on startup by default.

Make a new directory called scripts in the root directory and deploy.js in it.

mkdir scripts && cd scripts && touch deploy.js

Here is the deploy script. You deploy along with constructor values:

async function main() {
  const MyCryptoLions = await hre.ethers.getContractFactory("MyCryptoLions");
  const myCryptoLions = await MyCryptoLions.deploy("MyCryptoLions", "MCL");

  await myCryptoLions.deployed();

  console.log("MyCryptoLions deployed to:", myCryptoLions.address);
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

You might want to remove console.log() before you deploy. And then run this deploy script with:

npx hardhat run scripts/deploy.js
MyCryptoLions deployed to: 0x5FbDB2315678afecb367f032d93F642f64180aa3

Boom! Now your NFT contract is deployed to the local network.

You can target any network configured in the hardhat.config.js depending on your needs. You can find more about configuration here.

Wrapping Up

Hardhat has some other cool features like helpful stack trace, support for multiple Solidity compiler versions, a robust Mainnet forking, great TypeScript support and contract verification in Etherescan. But that’s for another time!

It took some time to get here. I started coding a few years after my college graduation. I wish I'd started earlier. Even after I started to program, I struggled to gain momentum.

What blocked me from starting and gaining momentum was a combination of my biased preconceptions, creative excuses, and wrong approaches.

If you are interested in programming but haven’t started yet, my story might help you to start right now. If you've started already but have been struggling to gain momentum, this story might help you build that momentum up.

How My Preconceptions Blocked Me From Starting Earlier

I was mostly brought up in a small city in the western part of Japan. In this city, almost nobody cared about computer technology. I was not an exception.

In my school, the computer lab was usually filled only with machines, and we humans were outside playing football. My family had an old Windows computer in the corner of a living room but nobody cared about it much.

Having been heavily influenced by my environment, I didn’t use a computer much up until high school. In college, I got my first cheap HP computer that my cousin chose for me. But I used it only for taking notes and surfing the Internet.

About a year and a half later, I was typing on a computer in a Silicon Valley startup during my summer vacation. I wish I had started coding back then, but no. I was not even planning to go there. I was there merely because this internship program looked more challenging in comparison to other options.

I remember that one of the interns there was teaching himself Perl. This was one of a few occasions where I was exposed to programming. But I didn’t even pay much attention to it. The idea of teaching myself programming didn’t even cross my mind.

Ever since I was labeled as a non-engineering student in high school (we have to choose between a humanities courses and science courses for a college exam), I had this almost unconscious preconception that I could not learn to code because I was not an engineering major.

Well, this was absurd. You don’t need a degree as long as you have a basic understanding of math. I’m talking about elementary school level math such as arithmetic operations that small kids are often able to learn within a month.

So don’t disqualify yourself. Everybody can learn to code. This amazing homeless person with no programming experience launched his iOS app in three months.

After graduating from college, I went to design school for my master’s degree. At this point, I was heavily inspired by the Silicon Valley startup culture through books and another visit there. That was one of the reasons why I chose to go to a design school. I wanted to teach myself how to design a product.

During a crash course prior to first semester, one class taught the basics of programming. Looking back, this was another good chance to get started, but I didn’t. I thought it was too late.

It’s funny that people in their early twenties (like my previous self) say that they are too old to start programming. If you google something like “programming am I too old”, you can find a bunch of examples of people who started relatively later in life like this one.

Chris Hawkes began programming at the age of 27. You can see that he knows an incredible amount of stuff if you watch his videos.

Is he too young for you? Jens Skou started programming at 70. And this woman built her first app at the age of 82! It’s too soon to say it's too late.

I came up with other nonsensical excuses such as “Soon AI is gonna code for us!” Looking back, those excuses probably came from my defense mechanism to avoid pain.

If you want to be a programmer, you should be willing to be the dumbest person in the room and embarrass yourself as a noob. And you know what, that’s how we improve ourselves. I don’t want to be the smartest person in a room. That’s the wrong room for me. I want to be surrounded only by smarter people.

I also don’t want to be the strongest person in a gym. I want to be the weakest so that I can learn from others and push myself harder. Learning to program is a great opportunity for you to be the dumbest.

How excuses and the wrong approach lead to false starts

My first serious attempt was when I started a lab project in grad school. We were prototyping an IoT device for pets. To see some activity in this device, we decided to make a mobile app.

Although we already had a programmer on our team, I volunteered to build the app with them. At that time, I didn’t even know what the heck HTML is.

With no basic knowledge, I ambitiously started to teach myself Objective-C, which is the language to build iOS apps. The other programmer had already started building, and I was told to buy a thick book about Objective-C.

I started to read the book and understood basic concepts like variables and functions, but it was boring. I remember I could not reason about it when the other programmer explained to me what his code was doing.

The gibberish code was overwhelming and I was confused. I couldn’t even explain what I didn’t know. I didn’t know where to start.

You want to be careful when you decide what to build initially. I should have started small and slowly layered up from there. The mobile app for the IoT device was too complex for me to wrap my head around back then.

Also, working with another programmer might not be a good idea initially unless the goal of a project is for you to learn. You want to learn at your own pace first.

In this first attempt, I gave up in less than a month. I told myself, “It doesn’t click for me. I should focus on my strengths.”

Now I want to tell my previous self that a programmer is the scribe of today. It is hard to imagine but people used to think that not everybody had to learn to read and write.

In our time, most of us still seem to think that not everybody has to read and write computer language. My hunch is that, in a not so distant future, everybody in this world is going to program.

Some progressive schools teach it already. Your kids will be surprised that you don’t know how to code. Programming will be both more essential and less professional as it spreads widely in our society.

Before the second year began, I ended up dropping out of grad school to work on a startup with my friend. I could design a bit back then, but I was mostly a marketing guy.

At that time I had to face my harsh reality: I was useless. Non-programmers are usually not helpful in the early stage of a tech startup because the most important thing at this stage is to get to a product-market fit.

To get there, we needed to build a prototype quickly, launch it early and often, test the idea, and then iterate on this process. It was frustrating and I was jealous to see other folks building a product.

After I left this startup, out of this creator envy, I applied to work as a software engineer intern in a small startup. I had spent some time going over some courses online, and luckily they let me in.

There were only two full-time developers, and they asked that I show some tangible results. They were writing Ruby on Rails, and again, I struggled to learn.

Unlike the first attempt, I was actually writing some code, but I still didn’t know what I was doing. I was simultaneously taking some online courses as well, but I didn’t feel like I was making good progress.

When you work for a company, you might have to build on top of other people’s code. This is what happened to me. All I did was fix their bugs or add small features. I didn’t know how the whole code worked, and I did not know what I was doing.

It’s great to work for a company because you might be able to meet a great mentor. But I don’t recommend committing to their existing code base at first because you might fail to understand the foundation. I’d say it's best to start by building something from scratch.

Put Yourself in a Situation Where You Have to Code

I left this startup pretty quickly, and I was thinking about what to do to brush up on my coding skills. Then when I was talking to my friend about it, he told me that he got a small gig online without even knowing how to get it done.

I liked this reckless idea, so I went to a crowdsourcing site and got a small gig. The gig was to build a simple form but I didn’t even know how to do that back then. But I faked it until I made it. The client was a bit angry at me (sorry!), but I somehow shipped the code.

I liked this approach for two reasons. The first was that I could build something from scratch as I mentioned before. The second was that this absolute necessity to code has become a forcing function for me.

I could've also done the work for my friends for free, but I liked that I was getting paid for the gig because then I had to get it done no matter what. Put yourself in a situation where you have to code.

You might feel that you are not ready to take a job, but I’d say it’s usually a good idea to start before you feel ready.

I am not saying that you don’t have to understand programming fundamentals. But we programmers are often required to start building with the minimum knowledge and learn on the fly anyway. We tend to do what we can’t. So start building before you feel ready.

I could have come up with what I wanted to build and worked on it but I didn’t. I think this was because I was trying to build something big or novel. If you are in the same situation, don’t let perfectionism or ambition stop you from starting. It’s not gonna be your last application.

Now I think of the learning process as climbing a wall. Initially, you don’t want to attempt the wall that is too high because it discourages you from starting. You might get exhausted and give up even if you do start.

Instead, deliberately try out a wall that is just beyond your current ability. Then climb that wall no matter what, learn a lot in the process, try out the higher wall next, and repeat. Eventually, you will find yourself building something complex.

The small gig was my turning point. After that, I took more jobs to build some landing pages and WordPress sites. From there, I made more dynamic applications such as other WordPress sites, and an e-commerce site for a client.

Along the way, I also built my own projects with ReactJS and Electron. I became unstoppable. I had finally gained momentum.

Coding Is the Closest Thing We Have to a Superpower

I made many mistakes along the way. If I was free from biased preconceptions and avoided creative excuses and wrong approaches, I could have gained momentum a lot earlier.

But I can say this: learning to program was one of the best decisions I’ve ever made in my life.

Programming has given me so much. It has taught me how to solve problems. It has allowed me to understand cutting edge technology in depth. It has given me the joy of building things. And it has given me the power to build a product and ship it to the world only with a small laptop.

“Coding is the closest thing we have to a superpower.”
Drew Houston, the Founder of Dropbox

Good luck! 💪