deno

dbffba80 - perf(snapshot): guard against lazy modules leaking into eager snapshot (#35332)

perf(snapshot): guard against lazy modules leaking into eager snapshot (#35332) ## Why #34450 moved the node-polyfill closure (`process` / `stream` / `net` / `tty` / `require` / the ~118 polyfill modules) out of the eager snapshot into `lazy_loaded_esm`, so non-node `deno run` / `eval` no longer deserialize it at startup (~28–31% faster on the common paths). Nothing guards that win. The closure stays lazy only as long as no eager `esm` entry — and nothing statically imported from one — references it. A single such import silently pulls a closure module back into the eager graph and regresses empty/ESM startup, with **no test going red**. It's a quiet, easy-to-reintroduce regression. ## What Pin the exact set of `lazy_loaded_*` specifiers that are legitimately consumed into the eager snapshot. The snapshot builder already reports them as `consumed_lazy_specifiers`; this asserts, at build time, that the consumed set is a subset of `EXPECTED_CONSUMED`. - Any lazy module **newly** reaching the eager graph fails the build, naming the offender at single-module granularity (well before a coarse size/count threshold would notice a partial leak). - Removals — a module *becoming* lazy, i.e. an improvement — are allowed. - The error message points at `ext/node/lib.rs` (the usual cause) and explains how to update the list for an intentional eager addition. Build-time only, zero runtime cost. ## Test - Builds clean on `main` (consumed set == `EXPECTED_CONSUMED`). - Negative test: removing an entry from the allowlist (simulating a leak) fails the build with `lazy module(s) newly pulled into the eager snapshot: ["…"]`.