This writeup is a continuation of my last post, where I go into how I am creating a full stack DApp within 30 days. This section will cover what I am using to build my DApp (specifically the Solidity parts).

Software Requirements

Let's go through what tools I'm using for this:

• Solidity v0.8.13

  The latest version of Solidity which will work with the tools I have installed.

• Foundry v0.2.0

  Foundry (Forge) is an Ethereum development tool released by Paradigm. It is faster, more flexible and (in my view) superior to Hardhat, which I have used previously. Notable benefits of Foundry are that tests are written in Solidity rather than JavaScript, tests can be done using fuzzing to allow for more comprehensively tested code, it is faster than alternatives and is gaining a foothold within the Solidity dev community. You could probably do the same things I am doing using Hardhat (in fact, it may be better for complete beginners) but I am going to use Foundry. Read more on Paradigm's website

  I will also be using the forge standard library which you can read about here. It contains useful tools for testing and learning how things work - I would consider it essential. GitHub

  GitHub will host my code at this repositoryVersion control is good practise, but I am the only dev involved here, so this is mainly to allow for workflow tracking and to keep everything nice and open source. I have stuff under a LGPL license (I just copied Sablier's license type) for now.

• VSCodium IDE

  I like VSCode. I don't like Microsoft sending telemetry when I use it. VSCodium exists for this reason.I am using the Solidity Syntax extension by contractshark since the most popular syntax highlighter highlights errors when I use it with Foundry.

Later on I will be using ReactJS for the frontend, but for the Solidity aspects, this is all you need!

Setup

I created a repo, put it under the LGPL license and ran forge init to create a starter template.

We can run this sample template by running forge test

Which produces the following output:

Now we have this running, it's important to note that the Solidity for the smart contract is in the src folder whereas tests (Foundry also uses Solidity for tests) are in the test folder. A test file has the .t.sol file ending rather than .sol (which is for contracts).

I renamed the files and imports which used the word Contract within these files and then re-ran the demo test to make sure it all runs.

Adding forge-std was as simple as following the guide and I ended up using emit log_string() as a version of JavaScript's console.log() function. You can also use console2.log(), in fact it is recommended, but I've used emit to log before so I am more used to it.

Using the VM for writing tests is super useful, although that's for another time. At this stage you should be ready to start building out your smart contract and playing around with Solidity.

This writeup is a continuation of my last post, where I go into how I am creating a full stack DApp within 30 days. This section will cover what I am using to build my DApp (specifically the Solidity parts).

Software Requirements

Let's go through what tools I'm using for this:

• Solidity v0.8.13

  The latest version of Solidity which will work with the tools I have installed.

• Foundry v0.2.0

  Foundry (Forge) is an Ethereum development tool released by Paradigm. It is faster, more flexible and (in my view) superior to Hardhat, which I have used previously. Notable benefits of Foundry are that tests are written in Solidity rather than JavaScript, tests can be done using fuzzing to allow for more comprehensively tested code, it is faster than alternatives and is gaining a foothold within the Solidity dev community. You could probably do the same things I am doing using Hardhat (in fact, it may be better for complete beginners) but I am going to use Foundry. Read more on Paradigm's website

  I will also be using the forge standard library which you can read about here. It contains useful tools for testing and learning how things work - I would consider it essential. GitHub

  GitHub will host my code at this repositoryVersion control is good practise, but I am the only dev involved here, so this is mainly to allow for workflow tracking and to keep everything nice and open source. I have stuff under a LGPL license (I just copied Sablier's license type) for now.

• VSCodium IDE

  I like VSCode. I don't like Microsoft sending telemetry when I use it. VSCodium exists for this reason.I am using the Solidity Syntax extension by contractshark since the most popular syntax highlighter highlights errors when I use it with Foundry.

Later on I will be using ReactJS for the frontend, but for the Solidity aspects, this is all you need!

Setup

I created a repo, put it under the LGPL license and ran forge init to create a starter template.

We can run this sample template by running forge test

Which produces the following output:

Now we have this running, it's important to note that the Solidity for the smart contract is in the src folder whereas tests (Foundry also uses Solidity for tests) are in the test folder. A test file has the .t.sol file ending rather than .sol (which is for contracts).

I renamed the files and imports which used the word Contract within these files and then re-ran the demo test to make sure it all runs.

Adding forge-std was as simple as following the guide and I ended up using emit log_string() as a version of JavaScript's console.log() function. You can also use console2.log(), in fact it is recommended, but I've used emit to log before so I am more used to it.

Using the VM for writing tests is super useful, although that's for another time. At this stage you should be ready to start building out your smart contract and playing around with Solidity.