Warning on Standard Contract deploy on mainnet

[bluesign]

Issue To Be Solved

Many new comers accidentally deploy FungibleToken, NonFungibleToken, NFTStoreFront contracts to their accounts, either because of a mistake or totally because they are uninformed.

Suggest A Solution

We can show a warning and prompt for confirmation in a case like this

[sideninja]

What would the warning be? Something like "it's advised you use already deployed contract ... read more about it here"

[bluesign]

It seems like you are trying to deploy %s to mainnet, it is a standard contract already deployed at address 0x%x. You can read more about it here: %s. Do you still want to deploy the contract (y/n)

I link we have already links for standard contracts at docs.

[sideninja]

That would be nice, I agree 100%.

[bluesign]

Are you ok holding this list in the CLI codebase ? Some kind of Contract Name -> ( mainnet address , web link ) mapping. I think it will be low maintenance

[sideninja]

I'm not a fan of lists of contracts, I feel that should be ideally decentralised and saved in such registries, so we don't special treat any contracts and control that ourselves, but that road is longer and I think it might be ok to do that meanwhile.

[bluesign]

@sideninja I did the most of the work here, but stuck on something.

Considering project deploy flow:

• Should we replace the contract reference in state with alias ?
• As we are not exposing direct access to state, should I add some helpers to Project, such as "ContractsToDeploy()andReplaceContractWithAlias` ? or is there a better place for this?

[sideninja]

Should we replace the contract reference in state with alias ?

This is a good idea yeah.

As we are not exposing direct access to state, should I add some helpers to Project, such as "ContractsToDeploy() and ReplaceContractWithAlias` ? or is there a better place for this?

Where are you trying to access state? In the project service you should be able to access the state directly.

[bluesign]

Because I want to prompt the user ( if they want to deploy or replace with alias ), so best option I guess:

• to do the check and prompt user ( on CLI side )
• depending on user answer, do the fix / or ignore
• deploy via flowkit project

So this flow will need access to state ( or some helpers accessing state as I mentioned )

[sideninja]

Because I want to prompt the user ( if they want to deploy or replace with alias ), so best option I guess:

• to do the check and prompt user ( on CLI side )
• depending on user answer, do the fix / or ignore
• deploy via flowkit project

So this flow will need access to state ( or some helpers accessing state as I mentioned )

You could do the prompt in the project service and then based on the answer you can proceed. In the future, we will refactor prompts out of the flowkit and just accept a prompt resolver as an argument, that way you could define the prompt in the command layer.

[bluesign]

@sideninja managed with prompt ui on project, but just one more question remains about where to save the config ( due to cascading -f edge cases ) or I can skip saving totally ?

[sideninja]

@bluesign we currently don't yet support saving to multiple files as per https://github.com/onflow/flow-cli/blob/7401e49afd2d7b89e15dc8f42c75fcb279f4e60f/pkg/flowkit/state.go#L79 There's a plan to make this work in the future once we find some time.