Plugin system

[jrhe]

Component

Other (please describe)

Describe the feature you would like

A plugin system to add additional tasks to both forge and cast is desirable.

• Users expect to be able to extend tooling, both with existing tools and their own scripts. I think this is probably particularly true for those coming from hardhat.
• Implementing a plugin system allows the scope of foundry to stay focused on testing/ building and chain interaction.
• Keeps the surface area of both forge and cast small, making them easier to learn and use.
• Can wrap functionality from other tools easily without re-implementing.

To illustrate, #610 suggests adding functionality to print the variable layout of a contract. This functionality is clearly useful, however:

• it doesn't obviously fall under the scope of forge or cask.
• the functionality is already implemented in slither and there is no obvious reason to reimplement it (speed etc).
• I expect the implementation would be fairly large, to be done in a reasonable way.
• it's not clear why you'd stop at just this one printer/ analysis out of the whole suite that slither implements.

Instead, a slither plugin could provide optional static analysis functionality from within foundry.

Additional context

No response

[ayushm2003]

Clap allows external commands by enabling external_subcommands. But this doesn't help in actually calling the asked command.

Cargo too allows external subcommands so I looked at some of its code to see how it invokes the called function. Looks like it internally makes use of std::process::Command. Can read some snippets here, here and here.

Maybe we can do this too, so a possible flow could look like -

• User implements plugins as a separate cli app on their system
• Sets the path to this program as env or smthng (cargo somehow searches for the command but probably overkill for our purpose)
• If foundry detects an unknown command, it uses std::process::Command to call the cli app with the arguments.

Would love everyone's thoughts on this and any other ways we can implement plugins.

[onbjerg]

I think another consideration for the plugin system is what kind of API we would expose, which requires us to think about some possible plugins that people would want to create. For example, I'd assume a lot of plugins would need access to things like the project config, artifacts and sources

[zerosnacks]

Hi @jrhe thanks for sharing your thoughts on plugins / extensions!

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

Would appreciate your latest thoughts on the topic in the extensions meta-tracking ticket: #8266

Closing this ticket (as duplicate) in favor of that one.