-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved config feature #198
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made a series of detailed commits that address various aspects of the logic. When new comments are fixed, I would appreciate it if you could thoroughly retest the entire flow to make sure everything is working correctly.
…to feature/update-swanky-config # Conflicts: # src/lib/command-utils.ts
@ipapandinas What do you think? If an account was created outside the project dir, should it be merged into |
@prxgr4mm3r I do not think so, if it's a personal dev account you do not want to share it publicly.
When setting the default account we can check if the alias belongs to the current account list. For example: Scenario 1
Scenario 2
Scenario 3
|
@ipapandinas What about accounts that are stored in the system config before the project is created? Should it be stored in the local config of the new project? |
@prxgr4mm3r good question but I don't think so. System account are personal accounts and project accounts are shared with project contributors. |
@prxgr4mm3r I created this commit 3a70313 on another branch to explore the possibility of using a config builder. The goal is to streamline the process of updating the configuration in a safe and controlled manner. What do you think? If you agree, you can cherry pick my commit and go from there. |
@ipapandinas I like this idea! Will work on that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
greatly improves the experience!
protected async loadAndMergeConfig(): Promise<void> { | ||
try { | ||
const systemConfig = getSwankyConfig("global"); | ||
this.swankyConfig = { ...this.swankyConfig, ...systemConfig }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't it be like { ...systemConfig, ...this.swankyConfig }
? or we are sure that they are disjoint, so it doesn't matter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here this.swankyConfig
holds the default state set during the buildSwankyConfig
init phase. I will rename it to make it clear: this.swankyConfig = { ...swankyDefaultConfig, ...systemConfig };
@@ -6,13 +6,15 @@ export class Query extends ContractCall<typeof Query> { | |||
|
|||
static args = { ...ContractCall.callArgs }; | |||
|
|||
static flags = { ...ContractCall.callFlags }; | |||
|
|||
public async run(): Promise<void> { | |||
const { flags, args } = await this.parse(Query); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this destructor shadow the new static flags
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After testing it, I've observed that this.parse
primarily uses static flags and args. However, I must admit is confusing..
src/commands/contract/new.ts
Outdated
|
||
await writeJSON(path.resolve("swanky.config.json"), this.swankyConfig, { spaces: 2 }); | ||
const configBuilder = new ConfigBuilder(getSwankyConfig("local")); | ||
configBuilder.addContract(args.contractName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: it might be a bit more convenient to make addContract
, addContractDeployment
methods more suited for the builder pattern (to return this
) - we could then chain all configuration into a single expression
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed! Let me adjust it
No description provided.