Is the generated code tree-shakeable?

[ferretwithaberet]

As the question states, is the generated code tree-shakeable? How would one build a library that would allow for tree-shaking?
is setting sideEffects: false in the package.json file enough?

[mrlubos]

That's a good question @ferretwithaberet. We have not focused on this yet, but it is one of the main criticisms of the original package as far as I'm aware. What are you building with it?

[mrlubos]

@schehlmj If it helps, I'll say that the goal is to enable anyone with a large API to create a client without the need to do custom workarounds like you're doing with the OpenAPI specification. We can build tooling for that so it would be standardised, that's a future feature though. For now, I'm interested in hearing more, your context is super helpful!

[schehlmj]

@mrlubos Would a design like the following be treehshakable?:
// userService.js export const getUser = (httpClient, username) => { return httpClient.get(/users/${username}`);
};

// workflowService.js
export const listPossibleNextSteps = (httpClient, workflowId) => {
return httpClient.get(/workflows/${workflowId}/next-steps);
};

// apiClient.js
import * as workflowsService from './workflowsService';
import * as userService from './userService';

export const createApiClient = (httpConfig) => {
const httpClient= httpClientFactory.create(httpConfig);

return {
workflowsService: {
listPossibleNextSteps: (workflowId) => workflowsService.listPossibleNextSteps(httpClient, workflowId)
},
userService: {
getUser: (username) => userService.getUser(httpClient, username)
}
};
};
`

[mrlubos]

I don't believe so. I'd need to play around with it, but by default it shouldn't be, because apiClient.js uses all imports and exports them as a function result. Maybe this could be worked around with /*#__PURE__*/ comments, I'd need to try + I am not sure if Rollup respects them too. It seems to support /*@__PURE__*/ though. So the answer is, maybe?

[schehlmj]

I'll say that the goal is to enable anyone with a large API to create a client without the need to do custom workarounds like you're doing with the OpenAPI specification

The API I am calling against is massive and unwieldy-- and I do prefer when I am generating the client, to not have all of its clutter. I go from thousands of schema types to under 200. Besides keeping the dist slim (which tree shaking also helps with), I like being able to use code completion to find the things I want/need easier.

I am lucky that I am able to generate a custom API spec-- and I think it would be really nifty if openapi-ts had the ability to do that itself. I basically say which API endpoints I need, and the the custom API spec generates a spec with just those and the schema that they use.

[mrlubos]

That's exactly what I was getting to. I am just not aware of how many people have really massive specs and what kind of issues they run into, it hasn't been discussed a lot yet. Would love to create a standardised API for that however, just like with the new clients, so people don't have to write their own custom requests, specs, etc. But this feels like another discussion, feel free to open a new thread if you want to pursue it further and see how many people are also interested

[mrlubos]

Starting with v0.46.0, services are tree-shakeable 🎉