etherscan verification failure (when remapping points to external file)

[adhusson]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (bf56869 2023-07-05T00:05:02.811991000Z)

What command(s) is the bug in?

forge script

Operating System

macOS (Apple Silicon)

Describe the bug

If you use files that are outside the project through a remapping (like@remapped/=../remapped/), and a file there does a relative import, then verification fails.

Reproduction

1. forge init bad_verif,

2. Add this to the initial bad_verif/foundry.ml:

remappings = ["@remapped/=../remapped/"]
allow_paths = ["../remapped/"]

3. Create remapped/ so that you have

.
├── remapped
├── bad_verif

4. In remapped/, create Parent.sol:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;
import "./Child.sol";

and Child.sol:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

5. In Counter.sol, add:

import "@remapped/Parent.sol";

6. Deploy with --broadcast --verify

Expected

Verification works.

Actual

If you deploy and verify, you will get the following error (I tried on polygon):

Fail - Unable to verify. Solidity Compilation Error: Source "../remapped/Child.sol" not found: File not found. Searched the following locations: "".

This is because the input json contains the following:

{
   "sources":{
      "src/Counter.sol": <content of Counter.sol>
      "../remapped/Parent.sol":{
         "content":"// SPDX-License-Identifier: UNLICENSED\npragma solidity ^0.8.13;\nimport \"./Child.sol\";\n"
      },
      "/Users/ah/temp/remapped/Child.sol": <content of Child.sol>
   },
   "settings":{
      "remappings":[
         "@remapped/=../remapped/"
      ],
   }
}

Suggestion

The key for Child.sol should probably use the relative path ../remapped/Child.sol instead of the absolute path /Users/ah/temp/remapped/Child.sol.

[PaulRBerg]

Update

This comment is outdated, please see #3507.

Original Comment

Any updates on this? It's a blocker for projects that use Node.js packages instead of git submodules.

We've bumped into this issue while deploying a new release of Sablier V2. Steps for reproduction:

1. Clone https://github.com/sablier-labs/v2-core
2. Checkout 6104b54
3. Run pnpm install
4. Run this command:

FFOUNDRY_PROFILE=optimized \
forge verify-contract 0x26a8515af672e4d66d71a941a3d6a3e9e5e61a8c \
./src/SablierV2LockupLinear.sol:SablierV2LockupLinear \
--chain sepolia \
--etherscan-api-key $API_KEY_ETHERSCAN \
--watch \
--constructor-args \
$(cast abi-encode "constructor(address,address,address)" 0xb1bEF51ebCA01EB12001a639bDBbFF6eEcA12B9F 0x2006d43E65e66C5FF20254836E63947FA8bAaD68 0xE8fFEbA8963CD9302ffD39c704dc2c027128D36F)

This is definitely a bug in Forge because the IERC165.sol file exists:

cat node_modules/@openzeppelin/contracts/interfaces/IERC165.sol
// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts v4.4.1 (interfaces/IERC165.sol)

pragma solidity ^0.8.0;

import "../utils/introspection/IERC165.sol";

cc @Evalir @mattsse

Interestingly, the verify command worked for a similar contract called LockupDynamic:

https://app.warp.dev/block/Pi8KR6PWF6cSqlpowkginR

It's strange because both contracts import stuff from OpenZeppelin (actually, they both import the exact same things).