Use --prose-wrap=never in prettier

Author: alcuadrado

docs/advanced/building-plugins.md

@@ -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`:
 
@@ -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
 

docs/advanced/migrating-buidler-plugin.md

@@ -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
 
@@ -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";
@@ -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
 

docs/config/README.md

@@ -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.
 
@@ -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:
 
@@ -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.
 
@@ -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:
 

docs/errors/buidler-errors.md

@@ -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
 
@@ -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.
 
@@ -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.
 
@@ -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.
 
@@ -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.
 

docs/getting-started/README.md

@@ -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
@@ -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:
 
@@ -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
 
@@ -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
 
@@ -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).