mirror of
https://github.com/strapi/strapi.git
synced 2026-06-02 16:27:47 +00:00
e56900bd07
Even with the lazy-fn pattern in Strapi.ts and compile.ts (#26266), deep tracing shows @strapi/typescript-utils still loads at boot via three independent paths: - `services/metrics/sender.ts` top-imports tsUtils for two `isUsingTypeScriptSync` calls inside the sender factory. Even when telemetry is disabled, importing the file loads tsUtils. - `services/metrics/index.ts` calls `createSender(strapi)` unconditionally, then `wrapWithRateLimit`. Both run when telemetry is disabled, even though their result is never used. - `admin/server/src/controllers/admin.ts` destructures `{ isUsingTypeScript } = tsUtils` at the module top, firing the require unconditionally. The function is only consumed by `GET /admin/project-type`. - `core/src/Strapi.ts` calls `tsUtils.resolveOutDirSync(...)` in the db factory even when `useTypescriptMigrations` is the default false, so the result is computed and thrown away. Surgical changes: - `metrics/sender.ts`: tsUtils becomes a lazy fn so loading the file is free. - `metrics/index.ts`: gate `createSender(strapi)` and `wrapWithRateLimit(...)` behind `!isDisabled`. - `admin.ts`: tsUtils becomes a lazy fn; isUsingTypeScript is a thin wrapper that resolves the require on first call. - `Strapi.ts`: `useTypescriptMigrations` check is hoisted; tsUtils resolves only when the flag is true. Measured (interleaved A/B, 12 runs each, fresh quickstart): - typescript-utils loads at boot: 17 -> 0 - median wall-clock: 1803 ms -> 1696 ms (-107 ms, above noise) Co-authored-by: Ben Irvin <ben.irvin@strapi.io> Co-authored-by: Ben Irvin <ben@innerdvations.com>