Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardhat Dependency Graph Doesn't Contain Nested Dependencies #2811

Open
pingdaze opened this issue Jun 9, 2022 · 6 comments
Open

Hardhat Dependency Graph Doesn't Contain Nested Dependencies #2811

pingdaze opened this issue Jun 9, 2022 · 6 comments
Labels
status:ready This issue is ready to be worked on type:improvement

Comments

@pingdaze
Copy link

pingdaze commented Jun 9, 2022

Local package file contains @openzeppelin/contracts version:4.6.0 but the 'arb-bridge-eth' package I'm using contains @openzeppelin/contracts version:3.4.2 and since the 4. update the repo doesn't contain Pausable.sol leading to a dependency issue since Hardhat is looking for the dependency in my root node_modules instead of the dependencies node_modules where it's actually located.
DUMPER.txt

@github-actions
Copy link
Contributor

github-actions bot commented Jun 9, 2022

This issue is also being tracked on Linear.

We use Linear to manage our development process, but we keep the conversations on Github.

LINEAR-ID: c84dd8b1-3628-48f0-b329-c818dabf299c

@fvictorio
Copy link
Member

Thanks for reporting this @pingdaze. This is a hard problem to solve because of the way solc works and how we use it. We are thinking of long-term solutions, but in the meantime we should:

  1. Detect that this is happening and throw a better error
  2. Add a section in our docs about how to deal with this scenario.

Note for ourselves: one way to do this is, during import resolution, and if we are resolving an import inside a library, check if that (second) imported library can be resolved both from the root of the project and from the (first) library. We should also get their respective versions, since that would be useful for the error message.

Notice that this can have an impact on performance, so we should probably cache this result, with the pair (lib1, lib2) as a key.

@Whytecrowe
Copy link

Any updates on this or at least some workarounds?

@alcuadrado
Copy link
Member

The current workaround is declaring dependencies as peer dependencies.

We are currently working on a new major version of Hardhat that properly supports this.

@Bilb
Copy link

Bilb commented Feb 25, 2025

Hey, any updates on this major version by any luck? I do have the same issue.
Besides, I am not sure how the peer dependency workaround could work, as some .sol files would be missing if I understand this correctly.
i.e. if I have
packageA -> openzeppelin/contracts@4.8
packageB -> openzeppelin/contracts@5.0

and I tweak one of those for it to be a peerDependency, the other one is going to be used instead.
So both would be using openzeppelin/contracts@5.0 or openzeppelin/contracts@4.8, and that would not compile in both cases (tried it already, some .sol are missing).
Any other ideas?

@fvictorio
Copy link
Member

Hey, any updates on this major version by any luck?

We released an alpha just this week! https://hardhat.org/hardhat3-alpha

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:ready This issue is ready to be worked on type:improvement
Projects
Status: No status
Development

No branches or pull requests

6 participants