For memory optimization reasons in the CLI, the generated Zod schemas were constructed so that all types for a request or response were contained within a single module. Now that the CLI is on the verge of no longer depending on Zod, I'd like to revisit this codegen strategy and look at reverting to reusable types in shared modules.
The @elastic/schemas bundle is currently ~500MB unzipped, in part because of Zod's redundant type definitions, especially because it is now supporting both ESM and commonjs exports, so there are two copies of every Zod schema in the bundle.
For memory optimization reasons in the CLI, the generated Zod schemas were constructed so that all types for a request or response were contained within a single module. Now that the CLI is on the verge of no longer depending on Zod, I'd like to revisit this codegen strategy and look at reverting to reusable types in shared modules.
The
@elastic/schemasbundle is currently ~500MB unzipped, in part because of Zod's redundant type definitions, especially because it is now supporting both ESM and commonjs exports, so there are two copies of every Zod schema in the bundle.