Add default foundry by anxolin · Pull Request #4 · cowprotocol/contracts-template

anxolin · 2026-01-21T19:13:33Z

Description

Boilerplate for a foundry project

Context

In order to have the discussions on our default configs, scripts, etc, I want to create a PR with the default foundry config, so every PR on top are the changes we want to apply to it.

This was created by running the following command in the main branch. With the excepttion of the README, which I deleted a bit of info:

# Force, cause the project is not empty
forge init --force

Out of scope

The goal of this PR is not to define the struture and confif yet, is just to commit the output of forge init --force as it is, so we can iterate and discuss the overrides of the default foundy.

Testing Instructions

Execute the following commands and ensure they are successful.

forge build
forge test
forge fmt
forge snapshot

kaze-cow · 2026-01-22T08:31:09Z

I reccomend here we actually use a configuration file similar to what we have got with Euler, as the one provided by default with foundry has some deficiencies imo

https://github.com/cowprotocol/euler-integration-contracts/blob/master/.github/workflows/test.yml

I will also comment on specific points to track

kaze-cow · 2026-01-22T08:34:03Z

+      - name: Install Foundry
+        uses: foundry-rs/foundry-toolchain@v1


We should lock the foundry version. Its an extremely common thing that foundry just updates and things break. We will need to remember to update the template project from time to time unforutnately though

- name: Install Foundry uses: foundry-rs/foundry-toolchain@v1 with: version: v1.5.1

Happy to do that in an interation PR. This PR aims to not change anything :)

Added a out of scope section to be more explicit on this.

kaze-cow · 2026-01-22T08:34:41Z

+        run: forge fmt --check
+
+      - name: Run Forge build
+        run: forge build --sizes


for best code quality, we should deny compiler notes.

- name: Run Forge build run: | forge build --deny notes --sizes

kaze-cow · 2026-01-22T08:38:22Z

+  workflow_dispatch:
+
+env:
+  FOUNDRY_PROFILE: ci


fork tests are really common, so would be nice to have this secret built in:

Also, if we can define org level secrets for all our RPCs we might want to use like $RPC_URL_1 (for mainnet, for example) that would be swell

env: FOUNDRY_PROFILE: ci FORK_RPC_URL: ${{ secrets.RPC_URL_1 }}

I agree the template should account for forked tests, but I wouldn't do it like this otherwise any random GitHub Action has access to this secret. I personally like to keep e2e tests separate from actual test in the workflow as well, but for simplicity we can just add the secret to name: Run Forge tests.

kaze-cow · 2026-01-22T08:40:29Z

@@ -0,0 +1,3 @@
+[submodule "lib/forge-std"]


we may consider replacing the gitmodules with NPM modules. In which case, submodules aren't necessary

This makes a lot of sense because cannon and extra linters we might use comes via a npm module also

I also don't really like submodules.
Well, I also don't like using package.json because we have nothing to do with JS and adding this file means we're pretending we are a JS module, and this has weird consequences sometimes.

As a concrete example, an issue I (somewhat) remember in the past is about the frontend having problems importing and updating the code from a contract repo once we introduced a package.json. This is because that files needs to (1) contain all expected parameters, like version and (2) the version parameter needs to be bumped each time anything meaningful change. If I remember correctly, not bumping the version when the code changed lead to the frontend ignoring any changes and didn't see the new updates until we realized about this issue. This hadn't been a problem before package.json was introduced, apparently previous imports would just rely on the commit hash for changes, but that was ignored after introducing that file.

I don't have an obvious best choice here, I'm fine with the code as it is at this point. Later if we think it's better, we can make this into a NPM package. I think we may want to eventually do that because a few linting tools (like solhint) are still best imported through NPM, but maybe we can try to hide this from NPM, possibly storing this file in dev/package.json or something like this.

kaze-cow · 2026-01-22T08:42:20Z

@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: UNLICENSED


We can probably remove this file. Most of the time we only use scripts for on-chain deployments, and thats pending/out of this PR scope.

kaze-cow · 2026-01-22T08:42:52Z

@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: UNLICENSED
+pragma solidity ^0.8.13;


Can probably tighten the required solidity version here to 0.8.30 or so

My suggestion would be to just use:

Suggested change

pragma solidity ^0.8.13;

pragma solidity ^0.8;

I know it's sometimes recommended to be tight in the versioning, but I never found the arguments convincing. I think it's fine to be permissive here while strict in foundry.toml.
My argument for being permissive is that sometimes I need to import relatively new contracts into an old repo; specifying a strict version means that the old project wouldn't compile and still keep deterministic deployments. This could happen, for example, if we want to add a test on an old repo that includes the new contract: we'd have to bump the Solidity version of everything, and so possibly redeploy, just to make tests work.

kaze-cow

basically it seems all changes from the foundry template are out of scope. so awaiting follow up PR to resolve my comments instead.

anxolin · 2026-01-23T11:28:46Z

basically it seems all changes from the foundry template are out of scope. so awaiting follow up PR to resolve my comments instead.

Yes, all comments are relevant and should be properly iterated in follow ups. I think makes it more clear the changes we apply on the default (otherwise, people can't tell what code in this PR came from the default and what is mine)

I will add it to #2

anxolin · 2026-02-18T20:22:18Z

@fedgiac I will add those in a follow up PR to not mix with the default foundry stuff

@fedgiac

## Description Follow up on #4 with a coment from @fedgiac I didn't want to mix in the "default foundry" setup (I'd like to have a PR with just foundry as it is, and then we can do small PRs to add bits and pieces) #4 (comment) ## Testing Instructions 1. Open Counter.t.sol Invert the order of the imports, so they look like ```solidity import {Test} from "forge-std/Test.sol"; import {Counter} from "../src/Counter.sol"; ``` 2. Run `forge fmt` It should invert again the imports leaving as they were ```solidity import {Counter} from "../src/Counter.sol"; import {Test} from "forge-std/Test.sol"; ``` If you use vscode and you have a solidity plugin (like me), chances are that the IDE formats it on save already, so no even need to do step 2

Add default foundry

154d926

kaze-cow reviewed Jan 22, 2026

View reviewed changes

kaze-cow requested changes Jan 22, 2026

View reviewed changes

kaze-cow approved these changes Jan 23, 2026

View reviewed changes

anxolin mentioned this pull request Jan 23, 2026

Potential reiteration of template project #2

Open

30 tasks

fedgiac reviewed Feb 17, 2026

View reviewed changes

Comment thread foundry.lock

Comment thread foundry.toml

anxolin merged commit f2a10e2 into main Feb 18, 2026
4 checks passed

anxolin mentioned this pull request Feb 18, 2026

feat: format inputs and add CI defaults #6

Merged

		- name: Install Foundry
		uses: foundry-rs/foundry-toolchain@v1

		@@ -0,0 +1,14 @@
		// SPDX-License-Identifier: UNLICENSED
		pragma solidity ^0.8.13;

Conversation

anxolin commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Context

Out of scope

Testing Instructions

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kaze-cow left a comment

Choose a reason for hiding this comment

Uh oh!

anxolin commented Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

anxolin commented Feb 18, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

anxolin commented Jan 21, 2026 •

edited

Loading

anxolin commented Jan 23, 2026 •

edited

Loading