microsoft
TS - kiota abstractions must be a peer dependency in auth and fetch library
When should you use peer dependencies? When you are building a library to be used by other projects, and This library is using some other library, and You expect/need the user to work with that other library as well
https://stackoverflow.com/a/34645112/10760931
Thanks for raising this. Assuming the abstraction lib is a peer dep for http, serialization and authentication packages, what would be the dependency story in msgraph-core? and in msgraph service libs? Would you have them + abstractions being a peer dep in msgraph-core and then being a direct dep in the service libs to lock down the versions?
Would you have them + abstractions being a peer dep in msgraph-core and then being a direct dep in the service libs to lock down the versions?
We will have abstractions as a dependency in graph core and service library.
the graph core depends on the interfaces for RequestOptions and authentication which are needed for a core only user as well.
but then following that logic, http/serialization/authentication which all depend on and expose abstractions interfaces should also have a dependency, not a peer dep.
@gavinbarron to provide input on this topic. I think the way we have it is absolutely OK and shouldn't be a peer dependency. Especially for a first-run experience that would add a lot of complexity IMO.
Interesting. I would strongly agree that we put abstractions as a peer dependency if it was an ever-changing lib. I think it has a pretty finalized api that doesn't change that often. Hence having it as it is works just fine. In the event things change api wise for abstractions, then setting it as a peer dependency will offer a better experience for http/authentincation/serialization lib usage.
