Reduce @sentry/node startup cost by flattening the published build #25680

require('@sentry/node') loads 589 CommonJS modules and takes about 92–100 ms on Node 24.21, measured against the local CJS build. NODE_COMPILE_CACHE brought no measurable gain, so the time goes to resolving, reading and evaluating many small files rather than compiling them. The packages are built with preserved modules, so each source file becomes its own published file. By module count the largest contributors are @sentry/server-utils, @sentry/core, @sentry/server-runtime-injection (its bundled parser and code generator) and @opentelemetry/api.

This cost lands on every cold start (serverless functions, CLIs, autoscaling containers).

Proposal

Reduce the cost through the build output shape. AGENTS.md rules out lazy loading as a fix, so imports stay static:

• Publish flattened entry files (instead of preserved modules) for @sentry/node, @sentry/server-utils and @sentry/server-runtime-injection, with the same exports maps and entry points.
• Check that nothing which only matters for runtime injection is evaluated on the main entry when it doesn't need to be, using a static restructure rather than lazy require.
• Measure before and after with the count-based gate proposed in the perf issue (modules loaded, import time).

Risks to check

• Deep imports into build/ paths
• @vercel/nft / Next.js file tracing
• The chunk layout that server-runtime-injection's hook.js relies on
• Dual-package hazards between the CJS and ESM builds

Related: #19885 takes a different approach to the same problem: a separate @sentry/core/light entry for lightweight consumers.