-
Notifications
You must be signed in to change notification settings - Fork 16
Description
Oleksii called me out hard 😄 for having an interface that will lead to unnecessary breaking changes. While I doubt many, if any, will create their own implementation of the IPasswordlessClient it is technically a breaking change to add a method to a public interface while it is not to add a new method to PasswordlessClient.
While I do like having interfaces for the purposes of mocking, the better more resilient thing to do is to make your own interface that you own in your application that wraps the usage you have of any said library. Bitwarden server follows this practice for our uses of Stripe with StripeAdapter. We should recommend users of our library, who want to mock our service, do the same.
What we can do today:
- Change examples and documentation that use
IPasswordlessClienttoPasswordlessClient - Stop adding new methods to
IPasswordlessClientand only add the implementation inPasswordlessClient.
When we do other and only when we do other breaking changes we can but don't have to:
- Make
IPasswordlessClienthave the[EditorBrowsable(Never)]attribute.- We could do this before a breaking change without actually breaking anyone but users who had previous uses of
IPasswordlessClientand want to use it elsewhere could be thrown off.
- We could do this before a breaking change without actually breaking anyone but users who had previous uses of
- Change the
AddHttpClientmethod usePasswordlessClientas service instead ofIPasswordlessClient- This changes logs from looking like:
System.Net.Http.HttpClient.IPasswordlessClient.ClientHandlertoSystem.Net.Http.HttpClient.PasswordlessClient.ClientHandlerthis is breaking because some users could use that category name to tune logs. Rare, but could cause some annoyance to consumers. - This doesn't need to be done other than people being slightly confused why the interface name is showing up in the logs when they don't use the interface at all.
- This also changes the name of the client for if people are manually configuring/injecting the
HttpClientthemselves, this is not a situation we support or document anywhere but it's something that can be done before that would no longer work.
- This changes logs from looking like:
- Write a recommended migration path of just removing the
Ifrom the type. - (NOT RECOMMENDED) we could also take a more aggressive approach and add
[Obsolete]to the type but I don't think this is warranted.