If I had to pick just one reason to use Foundry over Hardhat, it would be that I don't brick my entire repo when I try to upgrade and my yarn.lock dependencies collectively all shit themselves.

I love the Typescript language, hate the JS development ecosystem.

helping others build with LLMs and ML | YC S22, CMU CS + LTI | I write technical posts for ML builders at http://dbmikus.com

When you say “brick” are you referring to dependency trees, version bumps, etc. breaking? Like cannot resolve imports properly?

Or more that in JS ecosystem, APIs change relatively fast and folks don’t really adhere perfectly to semver, backwards compat, etc.

hypertext veteran • /mud core dev @lattice

For the former, I’ve had far fewer fights with dependency/version management in JS tools than say with Ruby.

But the latter is definitely true and can get messy, especially if you don’t have strong types, tests, and/or bump many packages simultaneously.

I have this weird triangle of dependencies between Hardhat, Ethers.js, and my Hardhat plugins and every once in a while they end up being incompatible or have API changes and stuff breaks.

If I did a clean install, everything would probably just work.

I like that Foundry is just `foundryup` and deps are isolated.

And for what it's worth, we have a monorepo so we have to reconcile our ethers.js version that Hardhat uses with what our web app uses.