The twenty CLI's esbuild only externalizes `twenty-client-sdk/{core,metadata}`
when bundling user logic functions and front components. Everything else is
inlined, including `twenty-sdk/define` — which transitively imports `zod` (and
all ~80 locales) and `@sniptt/guards`. Result: a 30-line `defineLogicFunction`
handler compiles to ~1.25 MB of .mjs + ~3.3 MB of .map per file.
`twenty-sdk/define` is an authoring surface: its `defineXxx` helpers only run
build-time validation, and manifest extraction already imports the real module
directly (via `manifest-extract-config-from-file.ts`, unchanged). At runtime,
the server just reads `default.config.handler` / `default.config.component` —
the validation result wrapper and zod schemas are dead weight.
This change adds a zero-dependency runtime stub that passes the config through
untouched, then aliases `twenty-sdk/define` → `twenty-sdk/define-runtime-stub`
in the app-bundle esbuild configs only. Build-time manifest extraction still
uses the real, validating module.
Result on a representative app (twenty-eng, 31 logic functions):
- logic-function .mjs: 1.26 MB → 332 KB (-75%)
- .mjs.map: 3.3 MB → 744 KB (-77%)
Front components still ship ~2 MB because `twenty-sdk/front-component` has the
same zod/sniptt pull-through — that's a follow-up with a different shape
(front-component helpers have real runtime behavior that the host injects, so
a blanket stub doesn't apply).
Charles Bochet
628fda5f0e