[APPS] Use manualChunks for self-contained backend function builds

[sdkennedy2]

Motivation

PR #317 originally moved inlineDynamicImports: true into the shared backend build config and refactored production builds to loop one vite.build() per function. A coworker pointed out that manualChunks: () => '[name]' — a pattern already used in this repo's own rollup config — achieves the same "no code splitting" goal while supporting multiple entry points in a single build call.

Changes

Replaced inlineDynamicImports: true with manualChunks: () => '[name]' in the shared backend build config. This lets us batch all backend functions into a single vite.build() call instead of looping one call per function.

The key difference: inlineDynamicImports only works with a single entry point (Rollup limitation), forcing us to build each function individually. manualChunks assigns all modules to the entry chunk, preventing code splitting while supporting multiple entries. This is the same pattern used at packages/tools/src/rollupConfig.mjs:193.

build-config.ts: Swapped inlineDynamicImports: true for manualChunks: () => '[name]' and moved entryFileNames: '[name].js' into the base config.

build-backend-functions.ts: Replaced the per-function loop (N vite.build() calls) with a single batched build — all virtual entries and inputs are collected up front, one build produces all outputs. Removes the no-await-in-loop eslint disable, emptyOutDir: false workaround, and per-function overrides.

dev-server.ts: No changes — builds one function per request and inherits the new config automatically.

QA Instructions

1. Scaffold or use an existing test app with 2+ backend functions
2. Link local build-plugins via yarn dev
3. Run vite build — verify each backend function produces a self-contained .js file
4. Run vite dev server — verify /__dd/executeAction still works for each function

Blast Radius

• Only affects the apps plugin's backend function build pipeline
• No changes to the main client build or any other plugin
• The dev server path is unchanged (still builds one function per request)

Documentation

• How to reliably make frontend production changes
• PR Description Guidelines
• Deploy steps

[sdkennedy2]

• [APPS] Use manualChunks for self-contained backend function builds #317 👈 (View in Graphite)
• [APPS] Add vite dev server middleware for backend functions #291 : 1 other dependent PR (#306 )
• [APPS] Use separate vite.build() for backend functions, drop Rollup backend support #292
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[datadog-official]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 3877b11 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}

[yoannmoinet]

Since we are working on customer's machine with this, I'd advocate for tight performances on this.

Not needed right away in this PR directly (so we can ship it asap), but in a soon-ish follow-up to have the builds made in parallel instead of sequentially, so its faster for the user.

Since this is something susceptible to run in CI, it will need some queueing system, in order not to flood the CPUs and memory capacities.

Multiple leads for it:

• the internal async-queue plugin, that allows you to defer the build and let the lifecycles of the build-plugins continue uninterrupted, but still hold the build process until these are finished. Works as a fire-and-forget deferral.
• PQueue usage with concurrency, example