feat: add a built-in console task

[galargh]

• Because this PR includes a bug fix, relevant tests have been included.
• Because this PR includes a new feature, the change was previously discussed on an Issue or with someone from the team.
• I didn't do anything of this.

---

Resolves #5575

This PR adds a console task to the next version of hardhat. Here's how it looks like:

$ # Show console task's help
$ 
$ pnpm hardhat console --help
Opens a hardhat console

Usage: hardhat [GLOBAL OPTIONS] console [--history <STRING>] [--no-compile] [--] [commands]

OPTIONS:

  --history         Path to a history file
  --no-compile      Don't compile before running this task

POSITIONAL ARGUMENTS:

  commands          Commands to run in the console

For global options help run: hardhat --help
$ 
$ # Run the console task and preview the `hre` context variable
$ 
$ pnpm hardhat console
> .help
.break    Sometimes you get stuck, this gets you out
.clear    Break, and also clear the local context
.editor   Enter editor mode
.exit     Exit the REPL
.help     Print this help message
.load     Load JS from a file into the REPL session
.save     Save all evaluated commands in this REPL session to a file

Press Ctrl+C to abort current expression, Ctrl+D to exit the REPL
> hre
HardhatRuntimeEnvironmentImplementation { userConfig: { tasks: [Array], plugins: [Array], privateKey: [Object] }, config: { plugins: [Array], tasks: [Array], path...

The task includes the following options:

• history - allows specifying the path where REPL history file should be stored. If it's relative, it will be resolved in the context of global hardhat cache dir. If it is explicitly set to an empty string, the history will not be preserved. It defaults to console-history.txt in the global hardhat cache dir. This is very helpful during testing, but I thought it might be useful to the users, too.
• noCompile - disables compilation task. This is not implemented yet.
• options - This is a hidden argument. It is not exposed to the users. It is only used during testing to set custom REPL options. In particular, we override the IO streams during testing because otherwise the test runner hangs indefinitely.
• commands - This is a variadic argument. One can provide a list of commands that should be executed in the REPL after the startup. It defaults to running the .help command after startup. This is very helpful during testing because we want to run the commands after the entire REPL setup fully complete there, but I thought it might be useful to the users, too.

Testing

• Added tests for the newly created task action; they are passing in CI
• Manually run the newly added task in the example-project; pnpm hardhat console

[changeset-bot]

⚠️ No Changeset found

Latest commit: 1870719

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
hardhat	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 14, 2024 2:00pm

[alcuadrado]

I did an initial review despite this being a draft. Looking good! I just left some minor comments.

[galargh]

Thanks for the initial review! I usually tend to use drafts for work-in-progress proposals which is pending my self-review. Here, it turned out not to be too far off from the final "ready for review" state ;)

[galargh]

I added a try-catch and a comment about an issue I observed in https://github.com/NomicFoundation/hardhat/actions/runs/10332073748/job/28602920453, for example. Have you seen something similar before? Do you think it's worth ensuring we can always delete the temp dirs in CI? In this particular case I think it might have something to do that the temp dir is on C: while the runner is set up to have perms and execute in the context of drive D:.

[alcuadrado]

that's actually sirprising, but I think we can live with it.

Maybe we should move it to the test utils package so that we don't hit this edge case again.

[galargh]

I created an issue for this - #5602 If I cannot resolve it, I'm going to add the utility function for this.

[alcuadrado]

This is really interesting! I never thought about it.

[alcuadrado]

This looks good! :)

I left a few comments, mostly about things that can be done later. Do you mind creating issues so that we don't loose track of them?

[schaable]

Nothing to add to Pato's comments. This looks great, nice work!