Chain Configs for the fuels CLI should be extendable off of the default one
Currently, if one wants to tweak a certain setting in the default chain config used by the fuels CLI, they would have to provide a whole new chain config file. They cannot just change one single setting.
There should be a way for people to create a custom chain config by extending the default one.
Incoming feedback from https://github.com/FuelLabs/docs-hub/pull/203
Could we generate a chainConfig.json with the scaffolded app and would that be enough to get the job done?
I haven't thought much about having the file as part of the template, but that could reduce the abstraction around everything. Especially considering it contains required configs, maybe we should consider showing it instead of hiding it.
Could we generate a
chainConfig.jsonwith the scaffolded app and would that be enough to get the job done?I haven't thought much about having the file as part of the template, but that could reduce the abstraction around everything. Especially considering it contains required configs, maybe we should consider showing it instead of hiding it.
I like this approach.
It would be good to have documentation in the README.md around:
- Pre-existing wallets (w/ assets) on the chain.
- Extending the chain with custom wallets.
- Links for the
chainConfig.jsondocumentation.
- Extending the chain with custom wallets.
Would a command for adding a new wallet be helpful?
npm wallet:new
# Pushes new wallet (w/ assets) to the `chainConfig.json`
# Displays the private key for usage in the app.
(Just a thought of a way to demonstrate the process)
Would a command for adding a new wallet be helpful? [...]
Seems to me that this could be a nice extension of forc-wallet, the workflow being similar to what you proposed:
forc wallet account new --chain-config ./chain-config.json
# Pushes new wallet (w/ assets) to the `chainConfig.json`
# Displays the private key for usage in the app.
# Adds some default coins
I haven't thought much about having the file as part of the template, but that could reduce the abstraction around everything. Especially considering it contains required configs, maybe we should consider showing it instead of hiding it.
Makes sense.
If we decide to go the extension way instead, for reference I already implemented type-safe chain config extending in #1356 (ref 1, ref 2).