TS - kiota abstractions must be a peer dependency in auth and fetch library

[nikithauc]

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

[baywet]

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?

[nikithauc]

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.

[baywet]

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.

[baywet]

@gavinbarron can you provide input on this one please?

[sebastienlevert]

@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.

[baywet]

@gavinbarron @musale I'd appreciate your input on this one

[musale]

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.