Support for foundry plugins written in Rust

[zemse]

Component

Forge

Describe the feature you would like

TLDR

This proposal suggests a possible way how Foundry can add support for plugins that add external subcommands (akin to tasks in hardhat) and register hooks (akin to subtask overrides in hardhat) which can enable faster experimentation for community and low maintenance effort to core team

Motivation

Currently, there are some foundry plugins written in Rust:

• https://github.com/wighawag/forge-deploy
• https://github.com/zemse/forge-flamegraph

These kinds of plugins suffer from poor DX for installation. A typical foundry user likely does not have cargo installed and users often have a low-power system like MacBook Air and it's not a good experience for every user to have to build a project. Also I don't think people would like to manually download the binaries from the releases page and put them in bin directory.

How could this work?

Installation

forge install <user>/<repo> can assess if it is a foundry external subcommand, download suitable binary from github releases, check integrity from release and add the binary to the bin directory of the system.

Usage

forge <something> could look for existence of a forge-something program and fork it. This is very similar to cargo's external subcommand.

Foundry <> Plugin API (nice to have)

Plugins are not blocked if Foundry does not explore some API, since they could just import foundry crates and still be able to do their job. I agree it's not ideal but fine for experimentation. For production-grade plugins, APIs could incrementally be added to Foundry as required.

IPC

The child process could efficiently communicate with forge through IPC and ask for any basic information like json outputs, source code as needed. Memory can potentially be shared, for e.g. if a plugin requesting debug traces which would be a huge data.

Hooks

Some plugins that are rather interested in adding logic during existing tasks, like for e.g. a plugin wants to do something before/after compilation or verification? hook flags (inspired from uni v4) could be added in the foundry.toml of the project and forge could trigger the plugin program at the appropriate event based on the flag.

Why to consider?

Faster experimentation

Currently, to put some experimental feature in the hands of a user, its API has to be designed properly, code has to be refactored to be high quality before being merged in the main branch. This costs time for external contributors as well as the foundry core team for reviewing.

Niche features

Sometimes niche features have a hard time making their way to the main branch. Think of various proxy patterns, draft EIPs, block explorers that have a non-standard API.

Low maintenance effort to core team

Once a feature makes their way in, usually it is difficult to remove it and have to maintain for eternity. The tech debt stays and maintaining it or removing it is an additional work. By enabling plugins, the effort of maintaining extra features go away. If some plugins are very popular, maybe foundryup could install them by default too (akin to hardhat-toolbox which installs popular plugins). Want to phase some plugin out? One line removal from the foundryup code and people who are interested to use the plugin could still separately install it by themselves through a single command forge install forge-something.

---

Related #706

Additional context

No response

[zerosnacks]

Hi @zemse, thanks for sharing your thoughts on extensions!

I'm supportive of adding extensions to Foundry, tracking extension related tickets here: A-extensions

It would be great if you can share your latest thoughts on the topic in the extensions meta-ticket: #8266

Closing this ticket (as duplicate) in favor of the meta-ticket, in an effort to have a more central place to discuss / spec ideas related to extensions.