Consider adding a way to run scripts withforc deploy

[nfurfaro]

I believe that forc deploy is the only way to deploy a sway contract.(oh, also by using the SDK :) )
Given the absence of constructors, the use of some form of initializer function is going to be common.
A known issue on ethereum when upgrading contracts is that sometimes the new contract is not initialized.

I propose adding a way to run a Sway script/scripts as part of the deployment process.
This could either be a cli options, ie --scripts=[script_1, script_2, scripts_3] or a new [scripts] field in the forc manifest.

This would allow forc deploy to deploy a group of contracts and set them up by calling the init function immediately.
Ideally, this whole process would be atomic and idempotent. That said, I don't know that this is 100% possible as deployment can't be done from a sway script.

Inspired by the hardhat-deploy plugin. It lets you add tags and dependencies to deployment/setup scripts, which lets you define the sequence in which scripts must be run. When deploying your dApp to a network, you just run the deploy command and everything gets deployed and initialized for you, but any scripts which have already been run against the current network won't run again. This would need to be enforced by the tooling or it would be a duplicate tx and therefore fail to run.

[adlerjohn]

The SDK would largely allow you to write deployment scripts, no?

[otrho]

Couldn't you kinda do the same just in a shell script -- forc deploy to get the scripts in and then forc run to initialise them?

[nfurfaro]

The SDK would largely allow you to write deployment scripts, no?

Yes. We don't need a new way to write deployment scripts. This is about wanting a way to run them that integrates nicely with the tooling (ie: forc).

Couldn't you kinda do the same just in a shell script?

You could, but given that we're trying to provide devs with a great UX with the whole toolchain, I feel that this is within the scope of what we could/should provide. Maybe this would best be implemented as a forc plugin. That way it integrates nicely but is not mandatory bloat for those who prefer to use bash. My feeling is that if it works well most people will just use it.

An example of usage: While working at The Sandbox, we needed extensive scripting to set up the Sandbox contract ecosystem. In order to run tests locally, we needed the deployments to mirror the ones on mainnet. Sometimes we needed to deploy a new contract on a testnet first, but it wouldn't work unless all the other contracts also existed on the same testnet.

A set of scripts (checked into version control) which can be run in the same way every time is needed to do this efficiently and reliably. Then you can run the same scripts in the same order on the local test node, on a persistent testnet or on mainnet with the same results each time.

We had over 100 scripts to run in order to bootstrap the system.

hardhat-deploy was the plugin we used to facilitate this process. The use of tags and dependencies in the scripts was a key piece of this, as it allows for defining the exact sequence in which these scripts must run, and also a way to check whether any given script had already been run on the current network and skip it if it had.

Here's an example script from the sandbox with tags and deps: https://github.com/thesandboxgame/sandbox-smart-contracts/blob/67a0d4b41c2bd693fdd1bbc085baed303a032438/deploy/08_game/01_deploy_gameToken.ts#L38