Improve binding generation

[fulminmaxi]

Component

Forge

Describe the feature you would like

My team has been using foundry and forge bindings in production for a few months, they're great but have a few rough edges, here is some feedback to make binding generation even better, in order of importance (for us at least):

• Provide a way to filter out tests, scripts and library related bindings. Today forge bind generates bindings for all contracts, and some of them (like bindings to forge-std contacts) are useless and add time to the build. In our repo, we delete 30 files and usually leave 2/3 (our actual contracts)

• Re-compile contracts by default. I personally shoot myself in the foot a few times by not recompiling before publishing our bindings, its easy to forget as all other forge commands re-compile before running.

• Use a fixed ethers-rs version instead of the latest one from github

Additional context

No response

[mattsse]

Use a fixed ethers-rs version instead of the latest one from github

could you elaborate on why this is more desirable? Do you need it for publishing your crate?

the reason we do this is, is because we're still adding new stuff and constantly fix things and it can take some time until a new release lands on crates.io

so unless you want to publish the project, imo it's preferable to depend on master and use the lock file.

[gakonst]

could you elaborate on why this is more desirable? Do you need it for publishing your crate?

i think we just forgot to bump the ethers version in the abigen'ed code

[fulminmaxi]

Use a fixed ethers-rs version instead of the latest one from github

could you elaborate on why this is more desirable? Do you need it for publishing your crate?

the reason we do this is, is because we're still adding new stuff and constantly fix things and it can take some time until a new release lands on crates.io

so unless you want to publish the project, imo it's preferable to depend on master and use the lock file.

Thanks for the super quick reply! We do publish the bindings to our internal cargo registry and use them in other repos (which I understand might be unusual), and I don't have a compelling argument for people building single repo apps, so its probably better to leave it as is

[onbjerg]

Fixed in the linked PRs above.