dx: migrate to foundry/forge

[sripwoud]

https://book.getfoundry.sh/forge/

Not urgent. And more a question: would contracts authors support this change?
Aiming for a faster local dx and ci.

Significant change. Especially all the tests will have to be rewritten. (forge tests are written in solidity, not in ts/js)

EDIT:
I suggest migrating to forge pkg after pkg to facilitate reviews and possibly work distribution (a single PR to cover everything would likely be huge)

• dx(excubiae): migrate to forge #26
• dx(imt): migrate to forge #27
• dx(lazy-imt): migrate to forge #28
• dx(lazytower): migrate to forge #29
• dx(lean-imt): migrate to forge #30

[0xjei]

https://book.getfoundry.sh/forge/

Not urgent. And more a question: would contracts authors support this change? Aiming for a faster local dx and ci.

Significant change. Especially all the tests will have to be rewritten. (forge tests are written in solidity, not in ts/js)

yes, I'd love to see this change for excubiae package.

[cedoor]

I think we can move on 👍🏽 It will take some time but it's not urgent as you said.

[sripwoud]

@0xjei in case you want to take #26
(I started the first forge PR: #23 )

[sripwoud]

after attempting a first refactor in #23, I have some questions and identified some challenges:
Do we want to support both forge and npm as a distribution mechanism for the contracts?

I'd say, we should aim at meeting the needs of most devs: hardhat and forge sol devs.

Regarding forge, the problem is that the way install works is repo based (org/repo), we need a foundry.toml at the top level of the repo. I don't think it is compatible with the way we currently split the contracts in sub npm packages.
To support both forge install and yarn install to distribute the contracts we need to either:

1. "flatten" this monorepo: eg take a look at https://github.com/OpenZeppelin/openzeppelin-contracts as an example
   in this case we would only have one package: e.g @zk-kit/solidity that includes all the contracts.
   We would be able to do:

• forge install privacy-scaling-explorations/zk-kit.solidity
• and yarn add @zk-kit/solidity

2. split all the packages in separate repos
   we would be able to do:

• forge install privacy-scaling-explorations/zk-kit.solidity.lean-imt
• and yarn add @zk-kit/lean-imt.sol

I am for 1. as it is more straightforward.
@cedoor @0xjei

[cedoor]

I don't like either of them 😄

1. How can we manage the versioning of individual libraries? Also difficult to manage audits if everything is inside a single package. IMO it goes against the idea of modularization that ZK-Kit promotes.
2. Very hard to maintain all those repos. A lot of duplicate configurations and dispersion. Also, very confusing for devs, who need to create a new repo in the PSE org if they just want to add a new package.

I agree we should support both of them tho 🤔 I wonder if there are any other solutions, maybe using submodules?

[sripwoud]

1. How can we manage the versioning of individual libraries?
   I guess we can't, we would loose that capability if we have one single big lib

2. We could use a github template to reduce the effort to create these repos, but there will be a big risk that each deviate from each other in terms of conf yes

3. There is the hardhat-foundry plugin. Didn't mention it earlier because that's the option I don't like so much 😆: I tried it, couldn't make it work immediately, so i gave up, concluding it was bad dx. I am not sure it can even work for a monorepo, the reason is that when using a node_modules dep with forge, you have to define a remapping for it. And with yarn, node_modules is 2 levels up in our monorepo. The remapping won't be valid when the sol package is installed (or is forge remappings smart enought to fix it?).
   ex:
   lean-imt will include a remappings.txt in its package with a content like
   poseidon-solidity\=../../node_modules/poseidon-solidity/contracts
   this relative path will be wrong after an yarn add @zk-kit/lean-imt.sol in another project

   Solution to this could be
   - stop using yarn workspaces
   - use another package manager/build system that does not hoist deps (pnpm or lerna support a no-hoist option)

[0xjei]

maybe this can help to take inspiration? https://github.com/PaulRBerg/foundry-template @sripwoud @cedoor

[cedoor]

@sripwoud We're already using pnpm in the snark-artifacts repo. If that solves the problem here I think we can switch to it, and maybe consider switching to pnpm in the other repos as well.

I would make sure we cannot solve the problem with Yarn first tho.