next.js

e1d82916 - Centralize node environment setup and config-dependent global behaviors

Centralize node environment setup and config-dependent global behaviors Currently node-environment is imported inconsistently — some entry points load it, others rely on downstream modules to eventually import it. This is fragile because it means the environment extensions (AsyncLocalStorage polyfill, error formatting, console patching, etc.) aren't guaranteed to be set up before other code runs. Similarly, installGlobalBehaviors is called separately from config loading even though it always needs to happen whenever config is produced. This PR makes two changes: 1. Add node-environment to all process entry points The three CLI commands (next-build.ts, next-dev.ts, next-start.ts) and start-server.ts (the forked child process entry point for next dev) now import node-environment at the top, before any other imports. This guarantees environment extensions are available before config loading, server initialization, or any other code runs. The import is removed from next-server.ts because NextNodeServer is never a process entry point — it's always constructed after a CLI entry point or start-server.ts has already loaded the environment. Other process entry points (export/worker.ts, static-paths-worker.ts, router-server.ts) keep their existing imports since they're separate processes. 2. Move installGlobalBehaviors into config loading installGlobalBehaviors (which configures console dimming for aborted requests) was called from two places — NextNodeServer constructor and export/worker.ts — separately from where config was loaded. This separated cause (config is available) from effect (global behaviors are installed) and meant every new config consumer had to remember to call it. loadConfig is renamed to loadConfigFromFile and now calls installGlobalBehaviors internally after resolving config. A new loadConfigForBuildWorker function handles the export worker case where config arrives pre-serialized via IPC rather than being loaded from disk — it also calls installGlobalBehaviors internally. Both use lazy require() for installGlobalBehaviors rather than a static import because console-dim.external.tsx depends on AsyncLocalStorage being on globalThis, which requires node-environment-baseline.ts to have run first. Static importing it from config.ts would trigger the dependency chain at module load time, before the environment is set up in contexts like the Jest test process that import config.ts transitively. The direct installGlobalBehaviors calls are removed from NextNodeServer and export/worker.ts — it's now an internal detail of config loading that consumers don't need to think about.