I’m starting to put some more thought into how the CLI could be better designed as a development tool and not just a utility to query the chain. I’m specifically interested in streamlining the local development workflow with the emulator.
Contract deployment and account management are two of the biggest pain points I’m seeing with both local (emulator) and testnet development. I think it’d be great if the CLI included better tooling to map contracts to accounts, especially when using the same contracts on multiple networks (emulator and testnet) or with multiple accounts on the same network.
in the Configuration example the souce for FungibleToken is NonFungibleToken
also Fungible token is always present just under different addresses
NonFungibleToken is not there on emulator, but it is there on mainnet and testnet
Under user and admin account there is a keys option. That looks like it is a private key
it would be nice if this key could be specified in a file outside of the project root. So say $HOME/.flow–.json and be configurable with an ENV var. FLOW_TESTNET_JSON_PATH or something like that
ideally this flow.json file should be checked in with the code, but not the pks on testnet/mainnnet
filling out the address for mainnet would be nice
filling out the addresses for other contracts that are available on testnet/mainnet like the CORE flow contracts would also be nice
also reusing contracts across projects would be nice, so what about beeing able to specify the url to the contracts as an URL?
Under user and admin account there is a keys option. That looks like it is a private key
it would be nice if this key could be specified in a file outside of the project root. So say $HOME/.flow–.json and be configurable with an ENV var. FLOW_TESTNET_JSON_PATH or something like that
ideally this flow.json file should be checked in with the code, but not the pks on testnet/mainnnet
in the Configuration example the souce for FungibleToken is NonFungibleToken
also Fungible token is always present just under different addresses
NonFungibleToken is not there on emulator, but it is there on mainnet and testnet
Thank you for noticing, this is fixed in PR #73.
I’m inviting you to share more of your good ideas on the issues you mentioned with the configuration keys.
What about contracts with init arugments? Should there be a default template for applying the contract and the posibility to use a custom one?
This ties neatly into the next enhancement, creating accounts that does not have contracts with them but that can be used for running transactions. Kinda like generate a new key, create an account for that key and add those to flow.json under a given name.
Then there is the problem of how do you specify an transaction? Make create a seperate json schema for how to specify a transaction? Read from a file/url and specify a list of arguments with a given type? One of the types could be an alias to an argument?
Also it would be nice if the option to run these contracts and apply projects could optionally emit things to stdout and read from stdin, so that they can be composed in a nice unix way.
This ties neatly into the next enhancement, creating accounts that does not have contracts with them but that can be used for running transactions. Kinda like generate a new key, create an account for that key and add those to flow.json under a given name.
Then there is the problem of how do you specify an transaction? Make create a seperate json schema for how to specify a transaction? Read from a file/url and specify a list of arguments with a given type? One of the types could be an alias to an argument?
For this, I was thinking we could start simple and just update the flow transactions send command to hook into the new contract address resolution code. For example, if a transaction imports a contract by file, the CLI could use flow.json to map that file to the correct address before preparing and signing the transaction.
Also it would be nice if the option to run these contracts and apply projects could optionally emit things to stdout and read from stdin, so that they can be composed in a nice unix way.
Great idea. How do you think the inputs/outputs should be formatted? These issues might be of interest to you:
I think that is a great idea. I was thinking to also enable different output serialization like JSON format and enable optional flags to just extract a single data from the output.
Example would be: accounts get 0x123 --balance
20
This way it can become even easier to compose commands.
This ties neatly into the next enhancement, creating accounts that does not have contracts with them but that can be used for running transactions. Kinda like generate a new key, create an account for that key and add those to flow.json under a given name.
I agree. We should also have a single command to do all you said.
I would really like it if we can work together on some of the features.
@bjartek I’m currently working on a CLI refactor and it will hopefully make things more consistent and output will have a unified structure. I was planning to support templates as well yes.