Add example deploy script

[TheRightChoyce]

This adds a working deploy script and also has an example of deploying a renderer along side the contract. In addition, it updates the following:

• Update .gitignore file to exclude .s.sol outputs and the broadcast logs
• Adds a basic CHAIN_ID ENV variable to use for the broadcast script
• Includes a Deploy.sh bash script for running the deploy
• Adds a note about using Solenv but does not actually add it as a requirement
• Adds an ignore for .s.sol files when generating types.

[holic]

Thank you!

Update .gitignore file to exclude .s.sol outputs and the broadcast logs

Is the .s.sol pattern common or recommended by Foundry? Haven't seen that yet and I think the .t.sol was following their patterns.

Adds a note about using Solenv but does not actually add it as a requirement

I wouldn't mind adding solenv as a requirement! Seems useful and a good practice to avoid manually juggling credentials.

Any thoughts on how we might extract some of the deploy script output into the deploy JSON files? e.g. contract addresses, etc.

[TheRightChoyce]

Is the .s.sol pattern common or recommended by Foundry? Haven't seen that yet and I think the .t.sol was following their patterns.

I saw it from the example in the scripting docs and found it useful. I didn't see a need for any of the outputs/ABIs in the front-end Dapp.

https://book.getfoundry.sh/tutorials/solidity-scripting?highlight=Scr#solidity-scripting

I wouldn't mind adding solenv as a requirement! Seems useful and a good practice to avoid manually juggling credentials.

I can add!

Any thoughts on how we might extract some of the deploy script output into the deploy JSON files? e.g. contract addresses, etc.

The broadcast outputs chunky json files, but they include all the correct information in a deterministic output file. Could just switch the path to those. Or could write a small script to parse the required output and write to the deploy files. Happy to hack on something and add to this PR : )

[holic]

The broadcast outputs chunky json files, but they include all the correct information in a deterministic output file. Could just switch the path to those. Or could write a small script to parse the required output and write to the deploy files. Happy to hack on something and add to this PR : )

We could probably use the same jq technique that current deploy script uses, just specify the keys we want to extract from the output JSON:

web3-scaffold/packages/contracts/deploy.sh

Line 17 in 50551e0

forge create $CONTRACT_NAME --json --rpc-url=$RPC_URL --private-key=$DEPLOYER_PRIVATE_KEY | jq . > $DEPLOY_OUTPUT

It'd be so great if this could be encapsulated in Solidity somehow so we don't have to run/maintain a separate script, but I'm happy with some of both if it means using Solidity scripting sooner than later!

[jamiew]

fwiw building a contract address book file from the foundry outputs was also my best solution so far.

I also dislike checking in the full broadcasts because they're so noisy, but that feels like the right pattern for history and being able to rebuild the address book

#checkingate continues

[TheRightChoyce]

@holic Added a jq line to the Deploy.sh script that will copy the relevant broadcast output to the existing "deploys" folder to remove the need for some manual copy/paste.

[holic]

what do you think about replacing the contracts/deploy.sh with this one?

[TheRightChoyce]

I think both are unnecessary : )

Do you want to try out the new deploy script a few times, and if it looks good, one of us pushes an update to remove the existing one?

[holic]

Can you share more about why both are unnecessary? The shell script is/was partly there to deploy the contract (now replaced by this solidity script 🙏 ) but also partly there to track the addresses for each contract so that the app, etc. can import them for wiring up contract interactions in the frontend. Is there another approach you're thinking for the latter step?

[TheRightChoyce]

I think I misunderstood the question / answered it poorly : )

I thought you referring to having both the deploy.sh file in the project root and also having one in the scripts folder. I think having at least one shell script is still necessary, but having two that do the same thing is not necessary. With anything that requires multiple flags or options to remember, I love have a easy script file to wrap all that up into a single command.