Skip to content

fix(cli): support shared foundry artifact deployments - #5132

Open
samsamtrum wants to merge 1 commit into
wevm:mainfrom
samsamtrum:fix-foundry-duplicate-abi-addresses
Open

fix(cli): support shared foundry artifact deployments#5132
samsamtrum wants to merge 1 commit into
wevm:mainfrom
samsamtrum:fix-foundry-duplicate-abi-addresses

Conversation

@samsamtrum

Copy link
Copy Markdown

Summary

Adds support for multiple named deployments sharing one Foundry ABI artifact in the CLI Foundry plugin.

Problem

When several deployed contracts share the same ABI artifact (for example DAI and WETH both using ERC20.json), the Foundry plugin can currently only emit the artifact contract name. That means only one generated config/address pair is available for the shared ABI use case.

Changes

  • Add a deploymentArtifacts mapping from deployment name to Foundry artifact name.
  • When resolving an artifact, emit additional contract entries for deployment names mapped to that artifact.
  • Keep the existing deployments address mapping behavior intact.
  • Add test coverage for two deployment names sharing one ERC20 ABI artifact.

Example:

foundry({
  deployments: {
    DAI: '0x1111111111111111111111111111111111111111',
    WETH: '0x2222222222222222222222222222222222222222',
  },
  deploymentArtifacts: {
    DAI: 'ERC20',
    WETH: 'ERC20',
  },
})

This allows generated exports such as both daiConfig and wethConfig while reusing erc20Abi.

Verification

  • corepack pnpm install --ignore-scripts --frozen-lockfile --filter @wagmi/cli...
  • corepack pnpm exec biome check --write packages/cli/src/plugins/foundry.ts packages/cli/src/plugins/foundry.test.ts
  • corepack pnpm exec vitest run packages/cli/src/plugins/foundry.test.ts -t 'contracts supports multiple deployment names sharing one ABI artifact'
  • corepack pnpm --filter @wagmi/cli run check:types

Closes #4396

@vercel

vercel Bot commented May 23, 2026

Copy link
Copy Markdown

@samsamtrum is attempting to deploy a commit to the Wevm Team on Vercel.

A member of the Team first needs to authorize it.

@changeset-bot

changeset-bot Bot commented May 23, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 86c111e

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

@promiseeuler promiseeuler left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While testing the new shared-artifact path locally on commit 86c111e, I found that watch mode only updates the original artifact contract, not the deployment aliases.

The initial contracts() call correctly returns ERC20, DAI, and WETH. After rewriting ERC20.json, however, plugin.watch.onChange(artifactPath) returns only:

{
  name: 'ERC20',
  abi: [{ name: 'after', /* ... */ }],
}

This comes from both callbacks selecting (await getContract(path))[0]. In generate --watch, that updates only the ERC20 entry in contractMap; the generated DAI and WETH configs keep the previous ABI until the process is restarted.

Could the watch contract support returning all resolved aliases (and remove all of them on unlink), with a regression test that changes the shared artifact after initial resolution? The current focused test passes, as does @wagmi/cli check:types; the additional watch regression fails because it receives the single ERC20 object instead of the three expected updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: foundry plugin multiple addresses referencing the same ABI

2 participants