Feature request: `--reset` flag for `hardhat deploy` task

[technophile-04]

Hello! We're currently migrating scaffold-eth-2 from hardhat 2 + hardhat-deploy v1 to hardhat 3 + hardhat-deploy v2 at scaffold-eth/scaffold-eth-2#1272

In v1, we had yarn deploy --reset which would force a redeploy even if the contract bytecode hadn't changed. This was useful during local development when you want a fresh contract instance on the same running chain (clean state, new address) without restarting the node.

In v2, the deploy task doesn't have a --reset flag. The alwaysOverride option on env.deploy() does the right thing at the API level, but there's no way to trigger it from the CLI.

What we're doing now:

We added a --reset flag via overrideTask("deploy") that sets an env var, and wrapped the deploy extension in rocketh/config.ts to read that env var and pass alwaysOverride: true:

// hardhat.config.ts
overrideTask("deploy")
  .addFlag({ name: "reset", description: "Force re-deploy" })
  .setInlineAction(async (args, _hre, runSuper) => {
    if (args.reset) {
      process.env.HARDHAT_DEPLOY_RESET = "true";
    }
    await runSuper(args);
  })
  .build();

// rocketh/config.ts
const deployWithReset = ((env: any) => {
  const deployFn = deployExtension.deploy(env);
  return (name: any, args: any, options?: any) => {
    const isReset = process.env.HARDHAT_DEPLOY_RESET === "true";
    return deployFn(name, args, { ...options, alwaysOverride: isReset || options?.alwaysOverride });
  };
}) as typeof deployExtension.deploy;

This works but the wrapper loses type safety (we have to cast through any because the deploy function is generic). Would be cleaner if the deploy task supported --reset natively, either by passing alwaysOverride through to all deploy scripts, or by clearing the deployment files before executing.

For context, the v1 --reset had issues (#300 , #130 ) around deleting all deployments when used with --tags. The alwaysOverride approach is actually better since it works per-contract, but it just needs a CLI entry point.

[github-actions]

📋 Tasks have been generated. Review the PR: https://github.com/wighawag/hardhat-deploy/pull/597

[wighawag]

Hey @technophile-04 thanks for creating this issue

I agree this would be useful, currently for my use case, I delete the deployments folder, like the old --reset

to have it behave like an automatic alwaysOverride, so it even work on specific tag deployment (without affecting other) I need to think a bit:

currently the deploy task has no knowledge of the rocketh extensions users add, so adding a --always-override could only be a signal that extensions like @rocketh/deploy but also other could read and implement as they wish.

I guess we could have a conventions maybe driven a --options "alwaysOverride" and implement it in @rocketh/deploy, @rocketh/proxy, etc...

But this means other implementing such extension would need to support it to not have unexptected behavior. But I do not see other options, except for the old --reset which could be implemented by rocketh core

[wighawag]

Another issue with alwaysOverride is that this will break replayability, so if the deployment execution is interupted, on re executing, it will override the step that have already been done

to be fair, this is the same issue for re-executing with --reset but here, the issue is stlightly more subtle as if you do not provide --alwaysOverride on the second run, then the other contract won't be overriden

This is not an issue for development where we do not expect it to be interupted and even if it is, it is not a problem to be overrident again, but not very like the idea

On that note, how did you deal previously with --reset and the need to reset only a specific set of contract (via tags) ? @technophile-04

[technophile-04]

Thinking more about lol it was getting complex, what would be the option for the --reset behavior.

On that note, how did you deal previously with --reset and the need to reset only a specific set of contract (via tags) ? @technophile-04

Actually while migrating to v2 and going in a bit deep I realised that --reset was wiping the whole thing. We actually didn't use the --reset alot while deploying to prod and while deploying locally never paired the --reset with --tags

And from hardhat-deploy perspective whoes one of the best feat is replayability it makes sense to omit the --reset flag because we already have the alwaysOverride which is more explicit and per deploy script based.

But just thinking more that flag actually added value for SE-2 users for rapid iteration on local chain.

one simple and easy path would be keeping the --reset flag behviour same as v1 but just adding cli prompt before and being clear that it will nuke deployments/<network>/ completely same pattern as the existing gas-price prompt (askBeforeProceeding in rocketh).

"This will delete all deployments for , including any successful, failed or in-flight state. Continue? y/n"

Now regarding the --reset --tags X behaviour we could just error out saying:

"--reset and --tags can't be combined, use alwaysOverride: true in your deploy script for tag-scoped resets.`"

Not sure it actually makes sense for hardhat-deploy and probably we could just add a proxy before the command hardhat deploy --reset and give user the same experience, but would be nice to have the hardhat-deploy inbuilt

And thanks for soo quick updates and looking after other issues!

[wighawag]

I added a --reset option in 2.0.6

I also remember now that I no longer use reset (which I used only for local dev) because rocketh now use genesisHash to detect different network and upon detecting a new one, it simply reset automatically

[wighawag]

Feel free to open a new issue for tag tracking.
I thought a bit about it and it might be possible though I am not sure it will be intuitive. Need more investigation

[wighawag]

here is some plan for tag tracking: wighawag/rocketh#45
Did not approve yet as I need to think through it a bit more and I am also interested of what you think: @technophile-04