Skip to content

Commit

Permalink
Use --prose-wrap=never in prettier
Browse files Browse the repository at this point in the history
  • Loading branch information
alcuadrado committed Jun 23, 2021
1 parent 57c4d17 commit a2c1ff1
Show file tree
Hide file tree
Showing 60 changed files with 207 additions and 463 deletions.
30 changes: 8 additions & 22 deletions docs/advanced/building-plugins.md
Original file line number Diff line number Diff line change
@@ -1,32 +1,20 @@
# Building plugins

In this section, we will explore the creation of plugins for Hardhat, which are the key component
for integrating other tools and extending the built-in functionality.
In this section, we will explore the creation of plugins for Hardhat, which are the key component for integrating other tools and extending the built-in functionality.

## What exactly are plugins in Hardhat?

Plugins are bits of reusable configuration. Anything that you can do in a plugin, can
also be done in your config file. You can test your ideas in a config file, and move
them into a plugin when ready.
Plugins are bits of reusable configuration. Anything that you can do in a plugin, can also be done in your config file. You can test your ideas in a config file, and move them into a plugin when ready.

When developing a plugin the main tools available to integrate new functionality are extending the
[Hardhat Runtime Environment](/advanced/hardhat-runtime-environment.md), extending the Hardhat config, defining new tasks and
overriding existing ones, which are all configuration actions achieved through code.
When developing a plugin the main tools available to integrate new functionality are extending the [Hardhat Runtime Environment](/advanced/hardhat-runtime-environment.md), extending the Hardhat config, defining new tasks and overriding existing ones, which are all configuration actions achieved through code.

Some examples of things you could achieve by creating a plugin are running a linter when
the `check` task runs, using different compiler versions for different files or
generating an UML diagram for your contracts.
Some examples of things you could achieve by creating a plugin are running a linter when the `check` task runs, using different compiler versions for different files or generating an UML diagram for your contracts.

## Extending the Hardhat Runtime Environment

Let’s go through the process of creating a plugin that adds new functionality to the Hardhat Runtime Environment.
By doing this, we make sure our new feature is available everywhere. This means your plugin users can access it from
tasks, tests, scripts, and the Hardhat console.
Let’s go through the process of creating a plugin that adds new functionality to the Hardhat Runtime Environment. By doing this, we make sure our new feature is available everywhere. This means your plugin users can access it from tasks, tests, scripts, and the Hardhat console.

The Hardhat Runtime Environment (HRE) is configured through a queue of extension functions
that you can add to using the `extendEnvironment()` function. It receives one parameter which is a callback which will be executed
after the HRE is initialized. If `extendEnvironment` is called multiple times, its
callbacks will be executed in order.
The Hardhat Runtime Environment (HRE) is configured through a queue of extension functions that you can add to using the `extendEnvironment()` function. It receives one parameter which is a callback which will be executed after the HRE is initialized. If `extendEnvironment` is called multiple times, its callbacks will be executed in order.

For example, adding the following to `hardhat.config.js`:

Expand Down Expand Up @@ -57,15 +45,13 @@ $ npx hardhat envtest
Hello, Hardhat!
```

This is literally all it takes to put together a plugin for Hardhat. Now `hi` is available to be used in
the Hardhat console, your tasks, tests and other plugins.
This is literally all it takes to put together a plugin for Hardhat. Now `hi` is available to be used in the Hardhat console, your tasks, tests and other plugins.

## Using the Hardhat TypeScript plugin boilerplate

For a complete example of a plugin you can take a look at the [Hardhat TypeScript plugin boilerplate project](https://github.com/nomiclabs/hardhat-ts-plugin-boilerplate/).

Plugins don't need to be written in TypeScript, but we recommend doing it, as many of our users use it. Creating a plugin in
JavaScript can lead to a subpar experience for them.
Plugins don't need to be written in TypeScript, but we recommend doing it, as many of our users use it. Creating a plugin in JavaScript can lead to a subpar experience for them.

### Extending the HRE

Expand Down
29 changes: 7 additions & 22 deletions docs/advanced/migrating-buidler-plugin.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,8 +18,7 @@ import { extendEnvironment } from "hardhat/config";

### Plugins

Similarly, references to Buidler plugins should be replaced with their corresponding Hardhat plugins.
For example, `@nomiclabs/buidler-ethers` would be `@nomiclabs/hardhat-ethers`.
Similarly, references to Buidler plugins should be replaced with their corresponding Hardhat plugins. For example, `@nomiclabs/buidler-ethers` would be `@nomiclabs/hardhat-ethers`.

## Adapting your plugin's source code

Expand Down Expand Up @@ -87,17 +86,15 @@ Then, you need to add an `import "./type-extensions";` in your `src/index.ts` fi

### Extending Hardhat types

Hardhat types are meant to be imported from `hardhat/types`, but when extending them,
you should import them from the module that declares them.
Hardhat types are meant to be imported from `hardhat/types`, but when extending them, you should import them from the module that declares them.

For example, if you want you use the `HardhatRuntimeEnvironment` type, you should import it with:

```typescript
import { HardhatRuntimeEnvironment } from "hardhat/types";
```

But if you want to extend it, you should import the module that declares it
instead, which is `hardhat/types/runtime`.
But if you want to extend it, you should import the module that declares it instead, which is `hardhat/types/runtime`.

```typescript
import "hardhat/types/runtime";
Expand All @@ -113,29 +110,17 @@ declare module "hardhat/types/runtime" {

Config types are handled slightly differently in Hardhat.

For each config element/type, there's two Typescript types defined. One
that ends with `UserConfig`, that represents the user's input, and another
one that ends with just `Config`, which represents the configuration values
after any resolution and default values have been applied. The first kind of
types is used by users when writing their config. The second one is used
during the execution of tasks, tests and scripts, and is present in the
Hardhat Runtime Environment.
For each config element/type, there's two Typescript types defined. One that ends with `UserConfig`, that represents the user's input, and another one that ends with just `Config`, which represents the configuration values after any resolution and default values have been applied. The first kind of types is used by users when writing their config. The second one is used during the execution of tasks, tests and scripts, and is present in the Hardhat Runtime Environment.

For example, `HardhatUserConfig` represents the entire config written by the
user, and all of its fields are optional. `HardhatConfig`, is the result
of resolving/normalizing it, and applying default values. None of its fields
are optional.
For example, `HardhatUserConfig` represents the entire config written by the user, and all of its fields are optional. `HardhatConfig`, is the result of resolving/normalizing it, and applying default values. None of its fields are optional.

Some types have been renamed to match this new pattern:

- `ProjectPaths` is now `ProjectPathsUserConfig`
- `Networks` is now `NetworksUserConfig`
- Both have their resolved versions: `ProjectPathsConfig` and
`NetworksConfig`, respectively.
- Both have their resolved versions: `ProjectPathsConfig` and `NetworksConfig`, respectively.

You can find an example of how to properly extend these types,
resolve/normalize the users's config, and apply default values in the
`src/type-extensions.ts` and `src/index.ts` files.
You can find an example of how to properly extend these types, resolve/normalize the users's config, and apply default values in the `src/type-extensions.ts` and `src/index.ts` files.

### How type extensions are loaded in Hardhat

Expand Down
29 changes: 8 additions & 21 deletions docs/config/README.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
# Configuration

When Hardhat is run, it searches for the closest `hardhat.config.js` file starting
from the Current Working Directory. This file normally lives in the root of your project. An empty `hardhat.config.js` is enough for Hardhat to work.
When Hardhat is run, it searches for the closest `hardhat.config.js` file starting from the Current Working Directory. This file normally lives in the root of your project. An empty `hardhat.config.js` is enough for Hardhat to work.

The entirety of your Hardhat setup (i.e. your config, plugins and custom tasks) is contained in this file.

Expand Down Expand Up @@ -47,19 +46,15 @@ module.exports = {

The `networks` config field is an optional object where network names map to their configuration.

There are two kinds of networks in Hardhat: [JSON-RPC](https://eth.wiki/json-rpc/API) based networks,
and the built-in Hardhat Network.
There are two kinds of networks in Hardhat: [JSON-RPC](https://eth.wiki/json-rpc/API) based networks, and the built-in Hardhat Network.

You can customize which network is used by default when running Hardhat by setting the config's `defaultNetwork` field. If you omit this config, its default value is `"hardhat"`.

### Hardhat Network

Hardhat comes built-in with a special network called `hardhat`. When using this network,
an instance of the [Hardhat Network](../hardhat-network/README.md) will be automatically created when you run a task, script or test your smart contracts
Hardhat comes built-in with a special network called `hardhat`. When using this network, an instance of the [Hardhat Network](../hardhat-network/README.md) will be automatically created when you run a task, script or test your smart contracts

Hardhat Network has first-class support of Solidity. It always knows which
smart contracts are being run and knows exactly what they do and why
they fail. Learn more about it [here](../hardhat-network/README.md).
Hardhat Network has first-class support of Solidity. It always knows which smart contracts are being run and knows exactly what they do and why they fail. Learn more about it [here](../hardhat-network/README.md).

You can set the following fields on the `hardhat` config:

Expand Down Expand Up @@ -89,17 +84,10 @@ You can set the following fields on the `hardhat` config:

- `hardfork`: This setting changes how Hardhat Network works, to mimic Ethereum's mainnet at a given hardfork. It must be one of `"byzantium"`, `"constantinople"`, `"petersburg"`, `"istanbul"`, `"muirGlacier"`, and `"berlin"`. Default value: `"berlin"`

- `throwOnTransactionFailures`: A boolean that controls if Hardhat Network throws on transaction failures.
If this value is `true`, Hardhat Network will throw [combined JavaScript and Solidity stack traces](../hardhat-network/README.md#solidity-stack-traces)
on transaction failures. If it is `false`, it will return the failing transaction hash. In both cases
the transactions are added into the blockchain. Default value: `true`
- `throwOnCallFailures`: A boolean that controls if Hardhat Network throws on call failures.
If this value is `true`, Hardhat Network will throw [combined JavaScript and Solidity stack traces](../hardhat-network/README.md#solidity-stack-traces)
when a call fails. If it is `false`, it will return the call's `return data`, which can contain
a revert reason. Default value: `true`
- `throwOnTransactionFailures`: A boolean that controls if Hardhat Network throws on transaction failures. If this value is `true`, Hardhat Network will throw [combined JavaScript and Solidity stack traces](../hardhat-network/README.md#solidity-stack-traces) on transaction failures. If it is `false`, it will return the failing transaction hash. In both cases the transactions are added into the blockchain. Default value: `true`
- `throwOnCallFailures`: A boolean that controls if Hardhat Network throws on call failures. If this value is `true`, Hardhat Network will throw [combined JavaScript and Solidity stack traces](../hardhat-network/README.md#solidity-stack-traces) when a call fails. If it is `false`, it will return the call's `return data`, which can contain a revert reason. Default value: `true`

- `loggingEnabled`: A boolean that controls if Hardhat Network logs every request or not. Default value: `false` for the
in-process Hardhat Network provider, `true` for the Hardhat Network backed JSON-RPC server (i.e. the `node` task).
- `loggingEnabled`: A boolean that controls if Hardhat Network logs every request or not. Default value: `false` for the in-process Hardhat Network provider, `true` for the Hardhat Network backed JSON-RPC server (i.e. the `node` task).

- `initialDate`: An optional string setting the date of the blockchain. Valid values are [Javascript's date time strings](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#Date_Time_String_Format). Default: The current date and time.

Expand All @@ -112,8 +100,7 @@ You can set the following fields on the `hardhat` config:

### JSON-RPC based networks

These are networks that connect to an external node. Nodes can be running in your computer, like Ganache, or remotely,
like Alchemy or Infura.
These are networks that connect to an external node. Nodes can be running in your computer, like Ganache, or remotely, like Alchemy or Infura.

This kind of networks are configured with objects with the following fields:

Expand Down
28 changes: 8 additions & 20 deletions docs/errors/buidler-errors.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
# Buidler errors

This section contains a list of all the possible errors you may encounter when
using Buidler and an explanation of each of them.
This section contains a list of all the possible errors you may encounter when using Buidler and an explanation of each of them.

## General errors

Expand Down Expand Up @@ -105,15 +104,13 @@ Please check that you are sending a `data` parameter.

### BDLR104: Unrecognized account

You are trying to send a transaction or sign some data with an
account not managed by your Ethereum node nor Buidler.
You are trying to send a transaction or sign some data with an account not managed by your Ethereum node nor Buidler.

Please double check your accounts and the `from` parameter in your RPC calls.

### BDLR105: Missing transaction parameter

You are trying to send a transaction with a locally managed
account, and some parameters are missing.
You are trying to send a transaction with a locally managed account, and some parameters are missing.

Please double check your transactions' parameters.

Expand Down Expand Up @@ -163,9 +160,7 @@ Try using another mnemonic or deriving less keys.

### BDLR200: Could not add positional param

Could add a positional param to your task because
there is already a variadic positional param and it has to be the last
positional one.
Could add a positional param to your task because there is already a variadic positional param and it has to be the last positional one.

Please double check your task definitions.

Expand Down Expand Up @@ -195,25 +190,19 @@ Please, double check your task definitions.

### BDLR210: Attempted to add mandatory params to an overridden task

You can't add mandatory (non optional) param definitions in an overridden task.
The only supported param additions for overridden tasks are flags,
and optional params.
You can't add mandatory (non optional) param definitions in an overridden task. The only supported param additions for overridden tasks are flags, and optional params.

Please, double check your task definitions.

### BDLR211: Attempted to add positional params to an overridden task

You can't add positional param definitions in an overridden task.
The only supported param additions for overridden tasks are flags,
and optional params.
You can't add positional param definitions in an overridden task. The only supported param additions for overridden tasks are flags, and optional params.

Please, double check your task definitions.

### BDLR212: Attempted to add variadic params to an overridden task

You can't add variadic param definitions in an overridden task.
The only supported param additions for overridden tasks are flags,
and optional params.
You can't add variadic param definitions in an overridden task. The only supported param additions for overridden tasks are flags, and optional params.

Please, double check your task definitions.

Expand Down Expand Up @@ -263,8 +252,7 @@ Please double check your arguments.

### BDLR302: Invalid file argument

One of your tasks expected a file as an argument, but you provided a
non-existent or non-readable file.
One of your tasks expected a file as an argument, but you provided a non-existent or non-readable file.

Please double check your arguments.

Expand Down
19 changes: 6 additions & 13 deletions docs/getting-started/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,8 +12,7 @@ A lot of Hardhat's functionality comes from plugins, and, as a developer, you're

Hardhat is used through a local installation in your project. This way your environment will be reproducible, and you will avoid future version conflicts.

To install it, you need to create an npm project by going to an empty folder, running `npm init`,
and following its instructions. Once your project is ready, you should run
To install it, you need to create an npm project by going to an empty folder, running `npm init`, and following its instructions. Once your project is ready, you should run

```
npm install --save-dev hardhat
Expand All @@ -25,8 +24,7 @@ To use your local installation of Hardhat, you need to use `npx` to run it (i.e.

This guide will explore the basics of creating a Hardhat project.

A barebones installation with no plugins allows you to create your own tasks, compile your Solidity code,
run your tests and run Hardhat Network, a local development network you can deploy your contracts to.
A barebones installation with no plugins allows you to create your own tasks, compile your Solidity code, run your tests and run Hardhat Network, a local development network you can deploy your contracts to.

To create your Hardhat project run `npx hardhat` in your project folder:

Expand All @@ -49,14 +47,11 @@ Welcome to Hardhat v2.0.8
Quit
```

Let’s create the sample project and go through these steps to try out the sample task and compile, test
and deploy the sample contract.
Let’s create the sample project and go through these steps to try out the sample task and compile, test and deploy the sample contract.

The sample project will ask you to install `hardhat-waffle` and `hardhat-ethers`, which makes Hardhat compatible with tests built with Waffle. You can learn more about it [in this guide](../guides/waffle-testing.md).

::: tip
Hardhat will let you know how, but, in case you missed it, you can install them with `npm install --save-dev @nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers ethers`
:::
::: tip Hardhat will let you know how, but, in case you missed it, you can install them with `npm install --save-dev @nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers ethers` :::

### Running tasks

Expand Down Expand Up @@ -168,8 +163,7 @@ Changing greeting from 'Hello, world!' to 'Hola, mundo!'

### Deploying your contracts

Next, to deploy the contract we will use a Hardhat script.
Inside `scripts/` you will find `sample-script.js` with the following code:
Next, to deploy the contract we will use a Hardhat script. Inside `scripts/` you will find `sample-script.js` with the following code:

<<< @/../packages/hardhat-core/sample-project/scripts/sample-script.js

Expand Down Expand Up @@ -206,5 +200,4 @@ npx hardhat run scripts/sample-script.js --network localhost

Congrats! You have created a project, ran a Hardhat task, compiled a smart contract, installed a Waffle integration plugin, wrote and ran a test using the Waffle and ethers.js plugins, and deployed a contract.

For any questions or feedback you may have, you can find us in the [Hardhat Discord
server](https://hardhat.org/discord).
For any questions or feedback you may have, you can find us in the [Hardhat Discord server](https://hardhat.org/discord).
Loading

0 comments on commit a2c1ff1

Please sign in to comment.