Closed Rubilmax closed 1 year ago
I think you can ask on the forge/foundry telegram group if there's a solution
A more solution-specific version of this issue is available here: https://github.com/morpho-dao/morpho-data-structures/issues/102
This issue is related to https://github.com/foundry-rs/foundry/issues/1855
I think I prefer the 3rd solution namely:
prefix imports with context-specific naming (name @morpho-utils/openzeppelin/contracts/Dependency.sol instead of @openzeppelin/contracts/Dependency.sol) requires root remappings.txt to map all the nested dependencies (is already the case, but is currently masked because dependency paths are shared through remappings)
As it allows to avoid duplication by hand (which can be annoying and prone to error) and it's rather easy to manage.
But solution 3) breaks compatibility with hardhat
(or at least require the developer to add remappings.txt
with all the remappings from the root + add a script to read remappings.txt
when compiling with hardhat
)
I think that this is not an issue here right ? Can we close it ?
Closed in favor of https://github.com/morpho-dao/morpho-data-structures/issues/102
Currently,
forge
compiles with the paths defined inremappings.txt
defined at a project's root. This is the source of compilation incompatibilities (sometimes even silent!) becauseforge
does not follow nestedremappings.txt
in submodules, which can lead to unexpected compilation resultsFor example, if
lib/openzeppelin-contracts/
's commit does not matchlib/morpho-utils/lib/openzeppelin-contracts/
's, we could get a compilation error or even a successful compilation, with a singleopenzeppelin-contracts
version used along withmorpho-utils
which wasn't necessarily built for:Possible solutions
../lib/openzeppelin-contracts/contracts/Dependency.sol
instead of@openzeppelin/contracts/Dependency.sol
@project/openzeppelin/contracts/Dependency.sol
instead of@openzeppelin/contracts/Dependency.sol
) 3.a. requires rootremappings.txt
to map all the nested dependencies (is already the case, but is currently masked because dependency paths are shared through remappings)