Refactor Configuration #654
Conversation
| usedOptions += ']' | ||
|
|
||
| // Check for consistent length across network options | ||
| const commonSize = new Set(arraysToCheck.map(a => a.length)).size |
There was a problem hiding this comment.
Do we need this check given that the next one checks for consistent in identification?
I have an idea that maybe instead of arraysToCheck, we can create a struct for network configurations, and try to fill them with the necessary fields; Everything is okay if we can successfully make a dict or array of network structs for all provided network identifiers, otherwise fail validations by missing or duplicated args? The network structs we make here can be returned and utilized later
There was a problem hiding this comment.
Thanks for the review!
I believe I did a somewhat similar refactor in #659.
Indexers will likely use untagged and single network configurations for the upcoming release, as using multiple networks will block the next database migration. |
|
Resolved by #668 |
Note:
Refactors configuration to accept the following options as lists instead of single values:
--network-provider(new name forethereum, which is now an alias)--epoch-subgraph--network-subgraph-endpoint--network-subgraph-deploymentIntroduces:
validateNetworkOptionsto sanitize the new cardinality of the network options.input-parsing.tsmodule with parsers for the new network identification format.To ensure compatibility, this PR restricts its scope to argument parsing and does not incorporate the network multiplexing changes expected from Refactor the Network component to hold different networks #652. which will resolve all the
FIXMESintroduced here.New dependencies:
parsimmon: for the newinput-parsing.tsmodule.lodash-countby: used in the newvalidateNetworkOptionsfunction.Closes #650