Merge branch 'main' into chore/merge-in-main

Author: kanej

.changeset/flat-hornets-yell.md

@@ -0,0 +1,5 @@
+---
+"@nomicfoundation/hardhat-verify": patch
+---
+
+Ink networks added

.changeset/fluffy-sloths-walk.md

@@ -0,0 +1,5 @@
+---
+"hardhat": patch
+---
+
+Fix heuristic to detect that an ESM project doesn't have a Hardhat config with an explicit `.cjs` extension.

.github/PULL_REQUEST_TEMPLATE.md

@@ -7,6 +7,15 @@ Please:
  - consider the checklist items below
  - keep the ones that make sense for your PR, and
  - DELETE the items that DON'T make sense for your PR.
+
+## Note about small PRs and airdrop farming
+
+We generally really appreciate external contributions, and strongly encourage meaningful additions and fixes! However, due to a recent increase in small PRs potentially created to farm airdrops, we might need to close a PR without explanation if any of the following apply:
+
+- It is a change of very minor value that still requires additional review time/fixes (e.g. PRs fixing trivial spelling errors that can’t be merged in less than a couple of minutes due to incorrect suggestions)
+- It introduces inconsequential changes (e.g. rewording phrases)
+- The author of the PR does not respond in a timely manner
+- We suspect the Github account of the author was created for airdrop farming
 -->
 
 - [ ] Because this PR includes a **bug fix**, relevant tests have been included.

.github/workflows/autoassign-issues.yml

@@ -15,8 +15,9 @@ jobs:
           script: |
             // each user has a chance of (p - (previousP ?? 0)) to be assigned
             const potentialAssignees = [
-              ["kanej", 1/3],
-              ["schaable", 2/3],
+              ["kanej", 1/4],
+              ["schaable", 2/4],
+              ["galargh", 3/4],
               ["ChristopherDedominici", 1.0],
             ];
 

.github/workflows/hardhat-core-ci.yml

@@ -18,6 +18,11 @@ on:
       - "packages/hardhat-core/**"
       - "packages/hardhat-common/**"
   workflow_dispatch:
+    inputs:
+      test-all-solc-versions:
+        description: Test all solc versions
+        required: false
+        default: "false"
 
 defaults:
   run:
@@ -63,6 +68,7 @@ jobs:
           DO_NOT_SET_THIS_ENV_VAR____IS_HARDHAT_CI: true
           FORCE_COLOR: 3
           NODE_OPTIONS: --max-old-space-size=4096
+          HARDHAT_TESTS_ALL_SOLC_VERSIONS: ${{ github.event.inputs.test-all-solc-versions}}
         run: pnpm test:except-provider
 
   test-provider:

CONTRIBUTING.md

@@ -139,3 +139,12 @@ When tests are run, Hardhat gets initialized multiple times, and that means unlo
 This problem is normally not present if you are monkey-patching an object that you initialized, but it is when monkey-patching a class, its prototype, or a singleton object initialized by the library itself.
 
 For an example on how to do it properly, please take a look at the `hardhat-truffle5` plugin.
+
+## Note about small PRs and airdrop farming
+
+We generally really appreciate external contributions, and strongly encourage meaningful additions and fixes! However, due to a recent increase in small PRs potentially created to farm airdrops, we might need to close a PR without explanation if any of the following apply:
+
+- It is a change of very minor value that still requires additional review time/fixes (e.g. PRs fixing trivial spelling errors that can’t be merged in less than a couple of minutes due to incorrect suggestions)
+- It introduces inconsequential changes (e.g. rewording phrases)
+- The author of the PR does not respond in a timely manner
+- We suspect the Github account of the author was created for airdrop farming

config/eslint/constants.js

@@ -1,5 +1,5 @@
 module.exports.slowImportsCommonIgnoredModules = [
-  "chalk",
+  "picocolors",
   "debug",
   "find-up",
   "fs-extra",

docs/README.md

@@ -37,7 +37,7 @@ To preview content locally, launch the app with `pnpm dev` and open http://127.0
 All content is organized by hierarchy levels and the top-level entries are layouts. The layout represents a set of folders and provides navigation within them. Currently, a folder should belong to one of the layouts. In terms of UI, the layout is equivalent to a sidebar navigation menu with two-level items. Layout settings can be found in the `src/content/layouts.yaml` file. It contains all layouts (currently "documentation" and "tutorial"). Each layout can have the following settings:
 
 - title (optional)
-- folders - the list of folders should be included in this layout
+- folders - the list of folders that should be included in this layout
 
 ### Folders
 
@@ -70,7 +70,7 @@ All documentation content is represented by `*.md` files with Markdown syntax. B
 
 ### Redirects
 
-Redirects allow you to redirect an incoming request path to a different destination path. Redirects settings are located in `redirects.config.js` file. It exports an array of objects. Each object represents a single redirect option. We utilize [NextJS Redirects](https://nextjs.org/docs/api-reference/next.config.js/redirects) API for that.
+Redirects allow you to redirect an incoming request path to a different destination path. Redirects settings are located in `redirects.config.js` file. It exports an array of objects. Each object represents a single redirect option. We utilize [NextJS Redirects](https://nextjs.org/docs/app/api-reference/config/next-config-js/redirects) API for that.
 
 ### Tabs
 
@@ -177,7 +177,7 @@ We also deploy updated storybook on each build. You can find it on https://hardh
 
 There are two relatively independent processes in the build step:
 
-1. Generating pages themselves. We get page paths directly from the files located in the content folder. Their paths are mapped to the page routes. Layout settings don't affect to page's existence.
+1. Generating pages themselves. We get page paths directly from the files located in the content folder. Their paths are mapped to the page routes. Layout settings don't affect page existence.
 2. Generating layouts and mapping layouts to pages. For that, we're checking which folders belong to what layout and assigning that layout to a page
 
 Page paths are generated in the `getStaticPaths` functions in files of the `page` folder. The result of these functions is an array of page paths. Page props are generated with the `getStaticProps` function, which is executed once per page with a page path passed as an argument and returns all required page props.
@@ -186,11 +186,11 @@ Execution of `getStaticPaths` and `getStaticProps` is handled by NextJS on a bui
 
 ## Styling
 
-We utilize [Linaria](https://github.com/callstack/linaria) for styling components. It has the "Styled Components" syntax but generates css without runtime with works fine with SSG sites.
+We utilize [Linaria](https://github.com/callstack/linaria) for styling components. It has the "Styled Components" syntax but generates css without runtime which works fine with SSG sites.
 
 ## Theming
 
-The documentation section is Themable. A user can switch between light, dark and high contrast themes for their convenience. There is also an "Auto" setting when theme is selected based on a user system settings.
+The documentation section is Themeable. A user can switch between light, dark and high contrast themes for their convenience. There is also an "Auto" setting when theme is selected based on a user system settings.
 
 Theming solution provides abilities to switch themes, keep the selected value in user's local storage, seamlessly keep selected page on navigating and page refreshing.
 
@@ -200,7 +200,7 @@ Landing pages don't support themes.
 
 ## Creating new landings
 
-Landing pages contains special "blocks" see src/components/landingBlocks. To create a new landing page start from copying `/pages/index.tsx` and `src/content/home.ts`. You can create another page by reordering existing blocks and passing another content to them. If necessary create new landing blocks.
+Landing pages contain special "blocks" see src/components/landingBlocks. To create a new landing page start from copying `/pages/index.tsx` and `src/content/home.ts`. You can create another page by reordering existing blocks and passing another content to them. If necessary create new landing blocks.
 
 ## CI/CD
 

docs/redirects.config.js

@@ -105,6 +105,12 @@ const customRedirects = [
       "https://cryptpad.fr/form/#/2/form/view/pV-DdryeJoYUWvW+gXsFaMNynEY7t5mUsgeD1urgwSE",
     permanent: false,
   },
+  {
+    source: "/solidity-survey-2024",
+    destination:
+      "https://cryptpad.fr/form/#/2/form/view/9xjPVmdv8z0Cyyh1ejseMQ0igmx-TedH5CPST3PhRUk",
+    permanent: false,
+  },
   {
     source: "/solc-viair",
     destination:

docs/src/components/CookiePopUp.tsx

@@ -21,7 +21,7 @@ const Container = styled.section`
   flex-direction: column;
   max-width: 332px;
   ${media.md} {
-    width: 332spx;
+    width: 332px;
     margin: 0px 24px;
     left: unset;
   }

docs/src/config.ts

@@ -22,14 +22,18 @@ export const SOCIALS_LINKS = {
   [SocialsEnum.DISCORD]: "/discord",
 };
 
-export const BANNER_LINK = "https://nomic.foundation/hiring";
-
 export const PRIVACY_POLICY_PATH = "/privacy-policy.html";
 
+// export const bannerContent = {
+//   text: "Join the Hardhat team! Nomic Foundation is hiring",
+//   shortText: "Join the Hardhat team! We are hiring",
+//   href: "https://nomic.foundation/hiring",
+// };
+
 export const bannerContent = {
-  text: "Join the Hardhat team! Nomic Foundation is hiring",
-  shortText: "Join the Hardhat team! We are hiring",
-  href: BANNER_LINK,
+  text: "Please take a few minutes to complete the 2024 Solidity Survey",
+  shortText: "Complete the 2024 Solidity Survey here",
+  href: "https://hardhat.org/solidity-survey-2024",
 };
 
 export const DOCS_PATH = path.join(process.cwd(), "src/content/");

docs/src/content/hardhat-chai-matchers/docs/migrate-from-waffle.md

@@ -8,7 +8,7 @@ The `@nomicfoundation/hardhat-chai-matchers` plugin is meant to be a drop-in rep
 
 1. Uninstall the `@nomiclabs/hardhat-waffle` and `ethereum-waffle` packages:
 
-   ::::tabsgroup{options="npm 7+,npm 6,yarn"}
+   ::::tabsgroup{options="npm 7+,npm 6,yarn,pnpm"}
 
    :::tab{value="npm 7+"}
 
@@ -34,11 +34,19 @@ The `@nomicfoundation/hardhat-chai-matchers` plugin is meant to be a drop-in rep
 
    :::
 
+   :::tab{value="pnpm"}
+
+   ```
+   pnpm remove @nomiclabs/hardhat-waffle ethereum-waffle
+   ```
+
+   :::
+
    ::::
 
 2. Then install the Hardhat Chai Matchers plugin:
 
-   ::::tabsgroup{options="npm 7+,npm 6,yarn"}
+   ::::tabsgroup{options="npm 7+,npm 6,yarn,pnpm"}
 
    :::tab{value="npm 7+"}
 
@@ -64,6 +72,14 @@ The `@nomicfoundation/hardhat-chai-matchers` plugin is meant to be a drop-in rep
 
    :::
 
+   :::tab{value="pnpm"}
+
+   ```
+   pnpm add -D @nomicfoundation/hardhat-chai-matchers
+   ```
+
+   :::
+
    ::::
 
 3. In your Hardhat config, import the Hardhat Chai Matchers plugin and remove the `hardhat-waffle` one:

docs/src/content/hardhat-chai-matchers/docs/overview.md

@@ -17,7 +17,7 @@ The `hardhat-chai-matchers` plugin is designed to work with `hardhat-ethers`. At
 
 ## Installation
 
-::::tabsgroup{options="npm 7+,npm 6,yarn"}
+::::tabsgroup{options="npm 7+,npm 6,yarn,pnpm"}
 
 :::tab{value="npm 7+"}
 
@@ -43,6 +43,14 @@ yarn add --dev @nomicfoundation/hardhat-chai-matchers
 
 :::
 
+:::tab{value="pnpm"}
+
+```
+pnpm add -D @nomicfoundation/hardhat-chai-matchers
+```
+
+:::
+
 ::::
 
 ## How can I use it?
@@ -146,7 +154,7 @@ await expect(contract.divideBy(1)).not.to.be.revertedWithPanic(
 
 You can omit the panic code in order to assert that the transaction reverted with _any_ panic code.
 
-The `revertedWithCustomError` matcher allows you to assert that a transaction reverted with a specific [custom error](https://docs.soliditylang.org/en/v0.8.14/contracts.html#errors-and-the-revert-statement):
+The `revertedWithCustomError` matcher allows you to assert that a transaction reverted with a specific [custom error](https://docs.soliditylang.org/en/v0.8.14/contracts.html#errors-and-the-revert-statement). Please note that this matcher does not check whether the error was emitted by the contract. It merely uses the contract interface to determine the full signature of the expected error. You can use it as follows:
 
 ```js
 await expect(contract.call()).to.be.revertedWithCustomError(

docs/src/content/hardhat-chai-matchers/docs/reference.md

@@ -66,7 +66,7 @@ await expect(token.transfer(address, 0)).to.be.revertedWithCustomError(
 );
 ```
 
-The first argument must be the contract that defines the error.
+The first argument must be the contract that defines the error. The contract is used to determine the full signature of the expected error. The matcher does not check whether the error was emitted by the contract.
 
 If the error has arguments, the `.withArgs` matcher can be added:
 
@@ -259,7 +259,7 @@ expect("0x1234").to.be.properHex(4);
 
 ### `.hexEqual`
 
-Assert that the given strings hexadecimal strings correspond to the same numerical value:
+Assert that the given hexadecimal strings correspond to the same numerical value:
 
 ```ts
 expect("0x00012AB").to.hexEqual("0x12ab");

docs/src/content/hardhat-network-helpers/docs/overview.md

@@ -13,7 +13,7 @@ This package provides convenience functions for quick and easy interaction with
 
 ## Installation
 
-::::tabsgroup{options="npm 7+,npm 6,yarn"}
+::::tabsgroup{options="npm 7+,npm 6,yarn,pnpm"}
 
 :::tab{value="npm 7+"}
 
@@ -39,6 +39,14 @@ yarn add --dev @nomicfoundation/hardhat-network-helpers
 
 :::
 
+:::tab{value="pnpm"}
+
+```
+pnpm add -D @nomicfoundation/hardhat-network-helpers
+```
+
+:::
+
 ::::
 
 ## Usage

docs/src/content/hardhat-runner/docs/advanced/artifacts.md

@@ -55,8 +55,8 @@ artifacts
     │   ├── Bar.json
     │   └── Bar.dbg.json
     └── Qux.sol
-        ├── Foo.json
-        └── Foo.dbg.json
+        ├── Qux.json
+        └── Qux.dbg.json
 ```
 
 Each Solidity file in your source will get a directory in the artifacts structure. Each of these directories contains one artifact (`.json`) file and one debug (`.dbg.json`) file for each _contract_ in that file. `Foo.sol`, for example, contains two contracts inside.

docs/src/content/hardhat-runner/docs/advanced/building-plugins.md

@@ -8,7 +8,7 @@ Plugins are bits of reusable configuration. Anything that you can do in a plugin
 
 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 a UML diagram for your contracts.
 
 ## Extending the Hardhat Runtime Environment
 

docs/src/content/hardhat-runner/docs/advanced/create-task.md

@@ -50,7 +50,7 @@ Tasks in Hardhat are asynchronous JavaScript functions that get access to the [
 
 For our example, we will use the [`@nomicfoundation/hardhat-toolbox`](/hardhat-runner/plugins/nomicfoundation-hardhat-toolbox), which includes the [ethers.js](https://docs.ethers.org/v6/) library to interact with our contracts.
 
-::::tabsgroup{options="npm 7+,npm 6,yarn"}
+::::tabsgroup{options="npm 7+,npm 6,yarn,pnpm"}
 
 :::tab{value="npm 7+"}
 
@@ -76,6 +76,14 @@ yarn add --dev @nomicfoundation/hardhat-toolbox @nomicfoundation/hardhat-network
 
 :::
 
+:::tab{value="pnpm"}
+
+```
+pnpm add -D @nomicfoundation/hardhat-toolbox @nomicfoundation/hardhat-network-helpers chai@4 ethers
+```
+
+:::
+
 ::::
 
 Task creation code can go in `hardhat.config.js`, or whatever your configuration file is called. It’s a good place to create simple tasks. If your task is more complex, it's also perfectly valid to split the code into several files and `require` them from the configuration file.