feat: `forge dependencies` to list details about installed dependencies

[mds1]

Component

Forge

Describe the feature you would like

The idea here is to make it easier to audit a project's dependencies and know which deps are core to the protocol, which are just for testing, etc. Very open to feedback, pushback, etc. as this is just my initial idea and not necessarily the best solution. I'd guess this gets trickier when someone isn't using submodules and is using npm/yarn, and in theory someone could be using both. But in general auditing deps is tedious right now and I think there's room for improvement.

I know there's #2618 so dep management might change, but I think a forge dependencies (open to other names) command could be useful regardless. This is arguably related to forge geiger which in theory should warn about deps with known vulns.

Existing Options

Right now git submodule status can show the installed versions of each dependency:

$ git submodule status
 9310e879db8ba3ea6d5c6489a579118fd264a3f5 lib/ds-test (heads/master)
 ca8d6e00ea9cb035f6856ff732203c9a3c48b966 lib/forge-std (v0.1.0-80-gca8d6e0)
 5f962edf98f2aeaf2706f7bfd07fac4532b42cc6 lib/murky (heads/main)
 66ec91bc450ff997ca7f7291491f7a1e49107767 lib/openzeppelin-contracts (v4.4.1-314-g66ec91bc)
 10fc959d987aab45f24e592d44449c723191ba2d lib/solmate (v6-157-g10fc959)

And you can use a command like this this to see if your deps are up to date (which really just means the latest main, which isn't great, ref #401 (comment)):

$ git submodule foreach 'git fetch -q; echo $"current: $(git rev-parse --short HEAD)\nlatest:  $(git rev-parse --short origin/HEAD)\n"' 
Entering 'lib/ds-test'
current: 9310e87
latest:  9310e87

Entering 'lib/forge-std'
current: ca8d6e0
latest:  d26946a

Entering 'lib/murky'
current: 5f962ed
latest:  5f962ed

Entering 'lib/openzeppelin-contracts'
current: 66ec91bc
latest:  046121e0

Entering 'lib/solmate'
current: 10fc959
latest:  bff24e8

There may be other ideas/solutions people have

Proposed Solution

I imagine the output being something like the below, with the key information shown being:

• A list of installed dependencies: their URLs, commit hashes, tags/branches if applicable, and if they are outdated
• Where each dependency is used: src, script, or test. Rationale being that in general, I'd scrutinize a dep more if used in production code compared to tests
• The above bullet can get tricky with recursive submodules, but would be great if that's handled properly. For example, maybe I install murky to help test merkle trees in test/ and to generate a merkle root in script/. But I don't use murky directly in src/. However, it has openzeppelin-contracts as its own dependency, and maybe I use that (without having installed it explicitly) in src/. It would be nice to know that I'm using that transitive dep and it's version in my production contracts

$ forge dependencies

======== Installed Dependencies =========
https://github.com/dmfxyz/murky
  Current version: 5f962ed
  ✅ Up to date

https://github.com/OpenZeppelin/openzeppelin-contracts
  Current version: v4.4.1-314-g66ec91bc
  Latest version: v4.7.3-xyz
  ❗️ Out of date

======== Dependency Tree Summary ========

src
  https://github.com/OpenZeppelin/openzeppelin-contracts

script
  https://github.com/dmfxyz/murky
  https://github.com/OpenZeppelin/openzeppelin-contracts

test
  https://github.com/dmfxyz/murky
  https://github.com/OpenZeppelin/openzeppelin-contracts

======== Dependency Tree ========

src
|-- MyToken.sol
     |-- lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol

etc., basically show everywhere deps are used

Additional context

No response

[zerosnacks]

Hey @mario-eth, would this be something you are interested in working on?

Scope would be to display both .gitmodules dependencies like this and the soldeer dependencies in a unified view

[mario-eth]

yea. Let me finish the current feature in soldeer and i'm gonna work on this.

[zerosnacks]

Awesome! Thanks

[Confucian-e]

Any update about this?

[mario-eth]

Any update about this?

Do we see any initial version where it requires less features?

Does list only dependencies at first works?

[zerosnacks]

Related: in #9522 we are introducing a foundry.lock file that will be able to be easily inspected as it is plain pretty formatted JSON.