Are the generated typescript clients tree shakeable?

[vkhobor]

It seems to me the client is an object that has all the methods attached and not separate inportable functions.

[baywet]

Hi, thank you for your interest in kiota and for reaching out.
We spent a lot of time optimizing for a bundle size over the last year. What remains is effectively an object with the important metadata to generate requests and most of the code is actually proxied so you don't pay the cost of all the different methods multiple times. You only pay that cost a single time.
You will also notice that we are emitting interfaces whenever possible to reduce again the amount of code that gets transpiled so the size is optimized as much as possible.
But yes, ultimately this object is not trimmable and this is why selecting only the operations you care about is important to get the smallest size possible. This is also why we resolved to using modular augmentation for the Microsoft graph packages.
Let us know if you have further questions or if you are facing issues with the size of your bundles.

[vkhobor]

Thanks. Do you have any links or references to read about this "modular augmentation", or how microsoft graph handles this?

[baywet]

Yes. Here is how we add all the apis under the /admin section of a graph API.
https://github.com/microsoftgraph/msgraph-sdk-typescript/blob/main/packages%2Fmsgraph-sdk-admin%2Findex.ts
Then, whenever users import this package, they get all the API surface that is related automatically under the main client.

[vkhobor]

Thanks again. I am not familiar with the kiota codebase, but as I have seen, it is possible to add new language support.

Do all new languages added will follow the fluent pattern or is it theoretically possible to make an alternative typescript adapter that uses a different programming style and supports tree shaking?

[baywet]

If it is in theory possible this is something more unlikely to accept. The first reason is because we want to have a single experience per language and not maintain multiple experiences for the same language and the second reason is because it will create difficulties for large apis.