terminal: load the output compactor on demand

[Dmitriy Vasyura (dmitrivMS)]

Summary

Keep the optional terminal-output compactor out of the initial workbench bundle. chat.tools.terminal.outputCompaction defaults to false, but its implementation was statically imported at startup.

• Emit the import-free compactor as a standalone ESM entry point and load it through FileAccess only when compaction is enabled and used.
• Preserve the configuration gate and algorithm. On load/compaction failure, preserve raw command output, log a warning, and retain existing failure telemetry.
• Include the standalone module in current and legacy desktop, web, and server-with-web build configurations; exclude headless server-only builds.
• Add coverage for the disabled gate, first use, compaction, and load failure.

Bundle impact

Compared real minified, NLS-enabled bundles at the same base revision:

Initial JavaScript bundle	Before	After	Reduction
Desktop workbench	19,297,489 bytes	19,222,792 bytes	74,697 bytes
Desktop Agents window	19,755,330 bytes	19,680,652 bytes	74,678 bytes

The desktop reduction is approximately 0.39%. The standalone module is 93,101 bytes including the standard build helper banner; this defers code rather than deleting it.

Verified that the implementation is absent from the initial source maps for desktop, Agents desktop, web, Agents web, and server-web. The three UI build targets emit byte-identical standalone modules with one source-map input and no imports.

First-use tradeoff

Five fresh real Code OSS windows hosted the exact production-built standalone module and exercised the production vscode-file:// loader:

• Zero compactor resource requests during startup.
• One resource request shared by concurrent and repeated imports, returning the same ESM namespace.
• First import: 8.9 ms median (8.2-25.2 ms); cached import: 0.1 ms median.
• Plain output unchanged; noisy sample compacted from 30,205 characters to 84 with the completion summary retained.

These are local first-use measurements, not web network latency or a complete terminal-tool invocation. No end-to-end startup-time improvement is claimed.

Validation

• Full product compilation and final client compilation/type checks passed; compile-client rerun before commit.
• Build-tool TypeScript checking passed.
• Repository hygiene passed on all seven staged files.
• Terminal-tool and compactor suites: 224 passing, 107 pending/skipped.
• Production builds passed for desktop, web, server-web, and server-only.

The Electron unit runner uses file://, so tests use a test-origin import adapter; the separate live-workbench checks cover the production resource URI.

[Copilot]

Copilot review overview

🟢 Approval recommended

The lazy-loading path, build-target coverage, fallback behavior, and focused tests are consistent and complete.

Review tier: Balanced
Findings: None

What changed in this PR

Defers terminal output compaction until first use, reducing initial workbench bundle size while preserving fallback behavior and telemetry.

Changes:

• Dynamically loads the standalone compactor through FileAccess.
• Adds the compactor to desktop, web, and server-web builds.
• Tests configuration gating, compaction, and load failures.

File	Description
runInTerminalTool.test.ts	Covers lazy loading and failure handling.
runInTerminalTool.ts	Implements on-demand compactor loading.
consoleCompactor.ts	Documents standalone-module constraints.
build/​next/​index.ts	Adds entry points to esbuild targets.
gulpfile.vscode.web.ts	Adds the legacy web entry point.
gulpfile.reh.ts	Adds the server-web entry point.
buildfile.ts	Defines and wires the standalone module.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.