Commit 2dc83be
feat: update provider type (#352)
* What is the current state of things and why does it need to change?
There should be an easy way to identify the type of provider. Account
discovery isn't limited to one group index, the discovery method should
be looping through indices and provide said index to `createAccounts`
* What is the solution your changes offer and how does it work? Add
`providerType` property, add `AccountProviderType` enum and remove
`groupIndex` from `discoverAndCreateAccounts`.
```gherkin
Feature: Account Provider Type Management
As a MetaMask developer
I want to properly identify and manage different account provider types
So that account discovery can work efficiently across multiple blockchain networks
Background:
Given the MetaMask accounts system is initialized
And the AccountProviderType enum is available
@provider-type @enum
Scenario: AccountProviderType enum contains all supported provider types
Given the AccountProviderType enum is defined
When I check the available provider types
Then I should see the following provider types:
| Provider Type |
| Evm |
| Solana |
| Btc |
And each provider type should be a valid enum value
And no additional provider types should be present
@provider-type @Validation
Scenario: Provider type property accepts only valid AccountProviderType values
Given I have an account provider instance
When I set the providerType to "Evm"
Then the providerType should be set to AccountProviderType.Evm
And the provider should be valid
@provider-type @Validation @error-handling
Scenario: Provider type property rejects invalid values
Given I have an account provider instance
When I attempt to set the providerType to an invalid value "InvalidType"
Then the system should reject the invalid provider type
And an appropriate error should be thrown
And the provider should remain in a valid state
@provider-type @evm
Scenario: EVM provider has correct provider type
Given I create an EVM account provider
When I check the provider type
Then the providerType should be AccountProviderType.Evm
And the provider should support EVM-specific operations
And the provider should be identifiable as an EVM provider
@provider-type @Solana
Scenario: Solana provider has correct provider type
Given I create a Solana account provider
When I check the provider type
Then the providerType should be AccountProviderType.Solana
And the provider should support Solana-specific operations
And the provider should be identifiable as a Solana provider
@provider-type @btc @future-proofing
Scenario: BTC provider type is available for future implementation
Given the AccountProviderType enum includes Btc
When I reference AccountProviderType.Btc
Then the Btc provider type should be available
And it should be ready for future BTC provider implementation
And it should not cause any runtime errors
@account-discovery @provider-identification
Scenario: Account discovery can identify provider types during discovery
Given I have multiple account providers:
| Provider Type | Status |
| Evm | Active |
| Solana | Active |
| Btc | Inactive |
When I perform account discovery
Then the discovery process should identify each provider by its type
And EVM accounts should be discovered using the Evm provider
And Solana accounts should be discovered using the Solana provider
And BTC provider should be skipped if inactive
@account-discovery @group-index-removal
Scenario: Account discovery works without groupIndex requirement
Given I have an account provider with providerType set
And the discoverAndCreateAccounts method is available
When I call discoverAndCreateAccounts without providing groupIndex
Then the method should execute successfully
And accounts should be discovered across multiple indices
And no groupIndex parameter should be required
@account-discovery @multiple-indices
Scenario: Account discovery loops through multiple indices
Given I have an EVM account provider
And there are accounts at indices 0, 1, and 2
When I call discoverAndCreateAccounts
Then the discovery should check index 0
And the discovery should check index 1
And the discovery should check index 2
And all discovered accounts should be created
And the discovery should continue until no more accounts are found
@provider-type @service-integration
Scenario: Service can use providerType for skipped providers functionality
Given I have a discovery service
And I have multiple providers with different types:
| Provider Type | Should Skip |
| Evm | false |
| Solana | true |
| Btc | true |
When I configure skippedProviders to include ["Solana", "Btc"]
And I perform account discovery
Then only the Evm provider should be used for discovery
And Solana provider should be skipped
And Btc provider should be skipped
And the service should identify providers by their providerType
@provider-type @type-safety
Scenario: Provider type ensures type safety at compile time
Given I have TypeScript compilation enabled
When I assign a valid AccountProviderType to providerType
Then the code should compile without errors
And type checking should pass
And IntelliSense should provide proper autocomplete
@provider-type @type-safety @error-handling
Scenario: Invalid provider type causes compile-time error
Given I have TypeScript compilation enabled
When I attempt to assign an invalid string to providerType
Then TypeScript should show a compilation error
And the error should indicate the expected AccountProviderType values
And the code should not compile until fixed
@provider-type @backwards-compatibility
Scenario: Provider type change maintains API compatibility
Given existing code that uses account providers
When the providerType property is accessed
Then the property should return an AccountProviderType value
And existing functionality should continue to work
And no breaking changes should be introduced to public APIs
@account-discovery @performance
Scenario: Account discovery performs efficiently without groupIndex constraint
Given I have providers for multiple blockchain types
And each provider has accounts at various indices
When I perform account discovery across all providers
Then the discovery should complete within acceptable time limits
And memory usage should remain within reasonable bounds
And the discovery should not cause performance degradation
@provider-type @integration
Scenario: Multiple providers can coexist with different types
Given I have the following providers configured:
| Provider Type | Instance Name |
| Evm | EthereumProvider |
| Solana | SolanaProvider |
When I access each provider's type
Then EthereumProvider.providerType should be AccountProviderType.Evm
And SolanaProvider.providerType should be AccountProviderType.Solana
And both providers should function independently
And provider types should not conflict with each other
@account-discovery @error-handling
Scenario: Account discovery handles provider errors gracefully
Given I have multiple account providers
And one provider throws an error during discovery
When I perform account discovery
Then the discovery should continue with other providers
And the error should be logged appropriately
And successful providers should still create accounts
And the overall discovery process should not fail completely
@provider-type @documentation
Scenario: Provider type enum is properly documented
Given the AccountProviderType enum is defined
When I check the JSDoc documentation
Then each enum value should have clear documentation
And the purpose of each provider type should be explained
And usage examples should be provided where appropriate
And the documentation should be up to date with the implementation
```1 parent 8cb6d45 commit 2dc83be
2 files changed
Lines changed: 22 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
| 1 | + | |
| 2 | + | |
| 3 | + | |
| 4 | + | |
| 5 | + | |
| 6 | + | |
| 7 | + | |
| 8 | + | |
| 9 | + | |
| 10 | + | |
| 11 | + | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1 | 1 | | |
2 | 2 | | |
| 3 | + | |
| 4 | + | |
| 5 | + | |
| 6 | + | |
| 7 | + | |
| 8 | + | |
3 | 9 | | |
4 | 10 | | |
5 | 11 | | |
6 | 12 | | |
| 13 | + | |
| 14 | + | |
| 15 | + | |
| 16 | + | |
7 | 17 | | |
8 | 18 | | |
9 | 19 | | |
| |||
33 | 43 | | |
34 | 44 | | |
35 | 45 | | |
36 | | - | |
37 | | - | |
| 46 | + | |
38 | 47 | | |
39 | 48 | | |
40 | 49 | | |
41 | 50 | | |
42 | 51 | | |
43 | | - | |
44 | 52 | | |
45 | 53 | | |
46 | 54 | | |
47 | 55 | | |
48 | | - | |
49 | 56 | | |
50 | 57 | | |
0 commit comments