Some ideas to improve foundry dev stack

[dionysuzx]

I developed a monorepo template for foundry here: https://github.com/d1onys1us/dapp-slaps

In doing so I found some small areas I thought would be great features (unless they already exist, and I couldn't find it in the docs):

1. Run wagmi-client generate (for ABIs) as a post-hook to forge script deployments. Running the wagmi-client in --watch mode feels like an extra step and I feel like it would be great if we can just hook into the process and generate the typed ABI in some output directory.
2. Option to exclude the full system path that is shown in the broadcast run.json files. This shows the root filesystem path and might not be desirable to expose for people if they commit some of the run.json files.
3. On the topic of the latest-run.json, there was something I wanted to solve but wasn't quite sure the best way to do it--I'll describe the issue: basically, I was using latest-run.json and looping over the CREATE calls to find the contract addresses for some contract of a given name (simple search through the json keys), and this works great if it is a single chain dapp. But if it is a multi-chain dapp, I can't statically reference what is the contract address because the file path is dynamic and depends on the chain id. Maybe the solution here is outputting some manifest.json which is a single json and includes all the mappings of chainId->[contractName->contractAddress]. Is there a way I can get some advice on how to build this? It would then mean I can just import a single static json and each time there is a broadcast / deploy that is rewritten and retriggers the HMR of the dapp and I always have the reference to the contract address for the context of the chain I have selected. (Also, maybe this is better served in the foundry plug-in for wagmi-client and can hook into the wagmi generate)
4. I felt that foundry was a bittt finnicky in a monorepo setup--specifically, that the foundry.toml root key, if I set it to some nested subdirectory path, basically a foundry.toml at the root of the monorepo but scripts/ src/ lib/ etc in some package at packages/foundry, then it would not work properly. Instead I had to manually prepend each path with packages/foundry/src, packages/foundry/lib, etc. I think first-class monorepo support would be great. I can provide more details if needed.

Finally, thanks for foundry and wagmi-client. It was a very nice experience I had pairing it w/ svelte to make a nice type safe, and reactive development environment. Really looking forward to further improving this stack.

[wighawag]

Hey, was going to post a discussion topic on similar matters. I ll add my comments:

1. I agree having a hook on watch would be great, I also need to generate some file from the result of the last broadcast. if forge script could return the content of latest-run.json and doing that on every execution via a watch hook that would be great

It would also avoid the potential issue of using latest-run.json where if the user were to execute 2 forge script command simulataneously there could be race condition

2. I agree, that sounds reasonable

3. Not sure it is exactly the same issue or if it can solve it, but I would like to have the ability to add metadata to the lastest-run.json . My use case: In hardhat world there is the concept of network name and they are very useful when you are building multiple independent system on the same "chainID"

My plan was to use env variable to let the user chose a network name and use that in my system, but if we could have that recorded in the output forge emit, that would be great.

For example for my game, especially on testnets, I have multiple version running. With hardhat I use different network name on the same chain to handle them independently.

5. I noticed issues in vscode too in a monorepo setup but did not yet isolate the specific issue

6. in the out folder, I noticed forge flatten the contract. and when there is file in a different folder with the same name as well as a contract of the same name in both, then one get overwritten. Also if you delete one of the file and recompile forge do not detect changes

7. in latest-run.json forge use contract name only (not the path) preventing us to know which contract it refers too, if both contract exist in different files