Verify flags and configs for subcommands #64
Conversation
| // set main config in `options` if config aliases are passed. | ||
| const aliasToMainConfig: {[key: string]: string} = {}; | ||
| allowedConfigs.forEach(config => { | ||
| config.alias.forEach(alias => { | ||
| aliasToMainConfig[alias] = config.name; | ||
| }); | ||
| }); | ||
|
|
||
| configsPassed.forEach((configName) => { | ||
| if (aliasToMainConfig[configName]) { | ||
| // `configName` is an alias | ||
| const mainConfig = aliasToMainConfig[configName]; | ||
| options[mainConfig] = options[configName]; | ||
| } | ||
| }); |
There was a problem hiding this comment.
In the case of configs, we would not use minimist for handling aliases but we'll handle them ourselves (to avoid polluting the src/index.ts file and get more control over aliases).
In the above block of code, if we encounter an alias set of options, we would set the main config name with the same value, so that we can rely on just the main config name in our scripts.
(Since we are not using minimist for aliases, the main config name will not be set automatically on options.)
|
@itsspriyansh Can you also check the failing tests when you get to it. It seems to me that we'd need to mock the |
|
@itsspriyansh We would need to write the tests for |
|
@garg3133 Just wanted to confirm what was the purpose of |
|
@itsspriyansh It is a replacement for the |
Naming conventions used in the PR:
command>subcommand>flag>configsandroidcommand has many subcommands, each representing an action that the user wants to perform.install --appmeans that the "install" action should be performed for "app".install --app, there can be a--path(APK path) and a--deviceId(id of target device) config.After this PR, we'll only use "options" to represent the options passed through the CLI. For other specific purposes, we'll use either "flag" or "configs".
Previous iteration of this PR: #51