HH415: Ambigious source name when remappings are used within sources.

[panukettu]

Version of Hardhat

2.17.3

What happened?

Hardhat does not compile a hybrid foundry project if remappings resolve to folders inside project sources.

Minimal reproduction repo: https://github.com/panukettu/hh-foundry-repro

This does work with [email protected] + @nomicfoundation/[email protected].

Minimal reproduction steps

hardhat config:

const config: HardhatUserConfig = {
  solidity: "0.8.19",
  paths: {
    sources: "./src/contracts",
  },
};

foundry.toml:

[profile.default]
src = 'src/contracts'
out = 'out'
libs = ['node_modules', 'lib']
test = 'test'
cache_path = 'cache_forge'
remappings = [
    'in-sources/=src/contracts/examples/',
    'outside-sources/=src/other/',
]

Now making an import eg. import {Lock} from "in-sources/Lock.sol"; will result in:

Error HH415: Two different source names ('src/contracts/examples/Lock.sol' and 'in-sources/Lock.sol') resolve to the same file

Search terms

remappings hardhat-foundry

[adaki2004]

As we do face the same, any update on the subject ?

[fvictorio]

For the record, the reason we do this is that source names with duplicated content can lead to weird compilation errors in some scenarios. This doesn't happen with forge build because in that case remappings are used, but Hardhat resolves the remappings itself.

But we should re-visit this, it might be unnecessarily limiting.

[panukettu]

For the record, the reason we do this is that source names with duplicated content can lead to weird compilation errors in some scenarios. This doesn't happen with forge build because in that case remappings are used, but Hardhat resolves the remappings itself.

But we should re-visit this, it might be unnecessarily limiting.

Right.. well it would be super if it could handle either this or include paths.

[duktig666]

Error HH415: Two different source names ('openzeppelin-contracts/proxy/ERC1967/ERC1967Utils.sol' and '@openzeppelin/contracts/proxy/ERC1967/ERC1967Utils.sol') resolve to the same file (/Users/renshiwei/code/company/NFT/nft-marketplace-contracts/lib/openzeppelin-contracts/contracts/proxy/ERC1967/ERC1967Utils.sol).

I have a problem like this.

forge-std/=lib/forge-std/src/
openzeppelin-contracts-upgradeable/=lib/openzeppelin-contracts-upgradeable/contracts/
openzeppelin-contracts/=lib/openzeppelin-contracts/contracts/
ERC721A-Upgradeable/=lib/ERC721A-Upgradeable/contracts/
ERC721A/=lib/ERC721A/contracts/
operator-filter-registry/=lib/operator-filter-registry/src/

"devDependencies": {
    "@nomicfoundation/hardhat-chai-matchers": "^2.0.0",
    "@nomicfoundation/hardhat-ethers": "^3.0.0",
    "@nomicfoundation/hardhat-foundry": "^1.1.1",
    "@nomicfoundation/hardhat-network-helpers": "^1.0.0",
    "@nomicfoundation/hardhat-toolbox": "^4.0.0",
    "@nomicfoundation/hardhat-verify": "^2.0.0",
    "@openzeppelin/merkle-tree": "^1.0.5",
    "@typechain/ethers-v6": "^0.5.0",
    "@typechain/hardhat": "^9.0.0",
    "@types/chai": "^4.2.0",
    "@types/mocha": ">=9.1.0",
    "chai": "^4.2.0",
    "dotenv": "^16.3.1",
    "hardhat": "^2.19.1",
    "hardhat-gas-reporter": "^1.0.8",
    "solidity-coverage": "^0.8.1",
    "ts-node": "^10.9.1",
    "typechain": "^8.3.0",
    "typescript": "^5.3.2"
  }

[rashtrakoff]

I am currently facing this issue. Is there an update on this? I get the following error message:

I am assuming if all my contracts use @openzeppelin/contracts then it should be solved? Any help is appreciated. Thanks!

[codyx]

If you are using hardhat-foundry and imported an npm package and a foundry submodule in the same repo with different remappings, then this issue will most likely occur.

It's possible to have an external library (such as OZ) referenced as both npm package and foundry submodule as long as you make sure that import names don't clash.

For instance, with OZ contracts you can have the following package.json:

    "@openzeppelin/contracts": "^5.0.0",
    "@openzeppelin/contracts-upgradeable": "^5.0.0",

And install submodules with forge like this:

$> forge install OpenZeppelin/[email protected]
$> forge install OpenZeppelin/[email protected]

Update your remappings.txt to:

[...]
@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/
@openzeppelin/contracts-upgradeable/=lib/openzeppelin-contracts-upgradeable/contracts/

And in your Solidity files, import like this:

import {ERC1967Proxy} from "@openzeppelin/contracts/proxy/ERC1967/ERC1967Proxy.sol";

That being said, I think it's cleaner to have external libraries referenced either as a foundry submodule or an npm package and not both at the same time, but in some situations you might want to do that.

[advock]

hey what's the solution to solve this ?

[RohanNero]

Running into this issue while using foundry remappings as stated previously.

Remappings.txt: ~=src/

npx hardhat compile outputs:

HardhatError: HH415: Two different source names ('src/interfaces/IERC20.sol' and '~/interfaces/IERC20.sol')

[matallui]

Same problem here when using hardhat with foundry. This is a deal breaker to using hardhat altogether for us.
In my case it's not even an issue with our project. We install a package A with forge install that contains a dependency B. Both A & B depend on C, but remap it differently.

[panukettu]

hey what's the solution to solve this ?

still using [email protected] in all projects affected by this

[Amxx]

hey what's the solution to solve this ?

still using [email protected] in all projects affected by this

[email protected] does not support Cancun (transient storage) :/

[panukettu]

hey what's the solution to solve this ?

still using [email protected] in all projects affected by this

[email protected] does not support Cancun (transient storage) :/

Yes, we stopped using it but legacy is pain