next-leak 0.11.1 → 0.11.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -29,22 +29,43 @@ next-leak found the growth, the retaining object and the chain that holds it —
29
29
  without being told what to look for. Next.js 16.3.0 has since fixed it.
30
30
 
31
31
  **Verified against real Next.js issues**, not synthetic fixtures. Issue states
32
- checked 2026-09-05:
32
+ checked 2026-09-19:
33
33
 
34
34
  | Issue | What it is | Measured | State today |
35
35
  |---|---|---|---|
36
- | [#97776](https://github.com/vercel/next.js/issues/97776) | `use cache`: `AbortSignal.any` composites never released (canonical issue; #97938 and #97464 are duplicates) | +705 KB per request on 16.3.3, flat on 16.2.6 (the #97938 run) | **open** — fix [#97476](https://github.com/vercel/next.js/pull/97476) merged Aug 19, in no stable release as of 16.3.4 |
37
- | [#97938](https://github.com/vercel/next.js/issues/97938) | `cacheComponents`: composite abort signal never released | +705 KB per request on 16.3.3, flat on 16.2.6 | closed Aug 31 as a duplicate of #97776; fix in no stable release |
36
+ | [#97938](https://github.com/vercel/next.js/issues/97938) | `use cache` / `cacheComponents`: `AbortSignal.any` composites never released (canonical issue since Sep 9; #97776 and #97464 are duplicates) | +705 KB per request on 16.3.3, flat on 16.2.6 | fixed in **16.3.5** (Sep 11) by [#98448](https://github.com/vercel/next.js/pull/98448), the backport of [#97476](https://github.com/vercel/next.js/pull/97476); re-measured Sep 14: +709 KB per request on 16.3.4, flat on 16.3.5 |
37
+ | [#97776](https://github.com/vercel/next.js/issues/97776) | `use cache`: the same composites, reported from production | the #97938 run above | closed Sep 9 as a duplicate of #97938; fixed in 16.3.5 |
38
38
  | [#96533](https://github.com/vercel/next.js/issues/96533) | ISR revalidation holds RSC buffers between collections | 4–5 MB of `arrayBuffers` held vs 0.32 MB retained | **open** |
39
- | [#97464](https://github.com/vercel/next.js/issues/97464) | Static-gen worker retains per prerendered page | OOM after 1617 and 1525 of 2504 pages on 16.3.3; 16.2.12 finishes at 0.05 MB/page | closed Aug 31 as a duplicate of #97776; fix in no stable release |
40
- | [#97802](https://github.com/vercel/next.js/issues/97802) | Turbopack compilation saturates the container before rendering anything | Reporter's reproduction in a 2 CPU / 4 GB container: 16.2.12 peaks ~2 GB and finishes; 16.3.0 pins 4 GB and stalls | **open** — bisected to 16.3.0; no fix known |
39
+ | [#97464](https://github.com/vercel/next.js/issues/97464) | Static-gen worker retains per prerendered page | OOM after 1617 and 1525 of 2504 pages on 16.3.3; 16.2.12 finishes at 0.05 MB/page | closed Aug 31 as a duplicate; same fix, in 16.3.5 — not re-measured here yet |
40
+ | [#97802](https://github.com/vercel/next.js/issues/97802) | Turbopack compilation saturates the container before rendering anything | not attributable to a version: see below. [#98581](https://github.com/vercel/next.js/pull/98581) (merged Sep 16, in `16.4.0-canary.34`) doesn't move it: cold build peak 5,161 MB on canary.33 and 5,279 MB on canary.35 (`next-leak build`); under 4 GB neither finishes compiling in 600 s, under 5 GB both compile in about a minute | **open** — the other fix from Vercel, [#98611](https://github.com/vercel/next.js/pull/98611), is still a draft |
41
+ | [#98707](https://github.com/vercel/next.js/issues/98707) | `next dev`: a route handler compiled after N pages costs ~16 MB × N | reproduced independently (10 pages, 34 handlers, Node 24.18): 851 MB on `16.3.0-canary.100`, **2,354 MB on canary.101**, 1,704 MB on 16.3.5; 1,461 MB requesting the handlers first | **open** — the reporter's bisect to `16.3.0-canary.101` holds |
41
42
  | [#92287](https://github.com/vercel/next.js/issues/92287) | Cache Components: unbounded `arrayBuffers` under load | 37.5 MB of arrayBuffers held between collections, 37x what it retains (16.3.1) | **open** |
42
- | [#84884](https://github.com/vercel/next.js/issues/84884) | axios + `AbortSignal` in middleware | 32.8 → 369.9 MB | **open** |
43
+ | [#84884](https://github.com/vercel/next.js/issues/84884) | axios + `AbortSignal` in middleware: a reference cycle through undici's `Request` finalizer, closed when Turbopack's scope hoisting inlines axios's `composeSignals` | +17.02 MB/1000 req on 16.3.5 (Node 24.18), +4.62 (Node 24.21); flat with scope hoisting off | **open** — still leaks on 16.3.5 and 16.4.0-canary.29; fix proposed in undici ([nodejs/undici#5822](https://github.com/nodejs/undici/pull/5822)); workaround: `experimental: { turbopackScopeHoisting: false }` |
43
44
  | [#89091](https://github.com/vercel/next.js/issues/89091) | zlib retention on mid-stream aborts | +42.5 MB/1000 aborted req on 16.1.5; **+0.03 on 16.3.1** | closed |
44
45
  | [#95094](https://github.com/vercel/next.js/issues/95094) | Middleware `setTimeout` ids retained by the sandbox | 112 MB retained; flat after the fix | fixed in 16.3.0 |
45
46
  | [#94890](https://github.com/vercel/next.js/issues/94890) | Router LRU cache doesn't count its keys | 26.7 → 71.9 MB | fixed in 16.3.0 |
46
47
  | [#94919](https://github.com/vercel/next.js/issues/94919) | Retention on client aborts | 39 → 139 MB · [with a caveat](#scope-and-limits-read-before-filing-issues) | fixed in 16.3.0 |
47
48
 
49
+ **#97802, and a measurement of ours that did not hold up.** Earlier versions of this
50
+ table said the regression was bisected to 16.3.0, on the strength of a 16.2.12 arm
51
+ that peaked around 2 GB while 16.3.x pinned the 4 GB ceiling. Re-measured on
52
+ 2026-09-16 in a real cgroup, that comparison falls apart:
53
+ `turbopackRustReactCompiler` does not exist before 16.3, so 16.2.12 rejects the key
54
+ and silently compiles through the Babel React Compiler while every 16.3 arm uses the
55
+ Rust one. Hold the version fixed and change only the compiler and
56
+ `16.3.0-canary.100` goes from 4,096 MiB with 12.3M at-limit events to 2,250 MiB with
57
+ zero. Give the Babel arms 2,400 s and neither 16.2.12 (2,180 MiB) nor 16.3.5
58
+ (1,692 MiB) ever reaches `Compiled successfully` — the low peak was unfinished work,
59
+ not headroom. With the compiler equalised and 6 GB of room, 16.3.5 is the only arm
60
+ that finishes the build at all, and what kills 16.2.12 and `canary.0` happens after
61
+ compilation, in prerendering. So this row no longer claims a version: the fixture
62
+ does not separate 16.2 from 16.3.
63
+
64
+ Two things worth taking from this if you measure builds yourself: when every arm
65
+ pins at exactly the cgroup ceiling, the ceiling is the measurement and not the
66
+ versions, so the peak cannot be the verdict; and an arm that never reaches the end
67
+ of compilation is not an arm that fits, however low its peak looks.
68
+
48
69
  The closed ones are kept deliberately: a tool that only lists open bugs
49
70
  looks impressive until the bugs close, and what those rows show is that the
50
71
  measurements matched what the fixes turned out to be. #94919 is the sharpest —
@@ -56,7 +56,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
56
56
 
57
57
  ---
58
58
 
59
- ## @babel/generator@7.29.7
59
+ ## @babel/generator@7.29.8
60
60
 
61
61
  License: MIT
62
62
  https://babel.dev/docs/en/next/babel-generator
@@ -184,7 +184,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
184
184
 
185
185
  ---
186
186
 
187
- ## @babel/parser@7.29.7
187
+ ## @babel/parser@7.29.8
188
188
 
189
189
  License: MIT
190
190
  https://babel.dev/docs/en/next/babel-parser
@@ -245,7 +245,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
245
245
 
246
246
  ---
247
247
 
248
- ## @babel/traverse@7.29.7
248
+ ## @babel/traverse@7.29.8
249
249
 
250
250
  License: MIT
251
251
  https://babel.dev/docs/en/next/babel-traverse
@@ -460,7 +460,7 @@ SOFTWARE.
460
460
 
461
461
  ---
462
462
 
463
- ## @memlab/core@2.0.4
463
+ ## @memlab/core@2.0.5
464
464
 
465
465
  License: MIT
466
466
  https://github.com/facebook/memlab#readme
@@ -491,7 +491,7 @@ SOFTWARE.
491
491
 
492
492
  ---
493
493
 
494
- ## @memlab/e2e@2.0.4
494
+ ## @memlab/e2e@2.0.5
495
495
 
496
496
  License: MIT
497
497
  https://github.com/facebook/memlab#readme
@@ -522,7 +522,7 @@ SOFTWARE.
522
522
 
523
523
  ---
524
524
 
525
- ## @memlab/heap-analysis@2.0.4
525
+ ## @memlab/heap-analysis@2.0.5
526
526
 
527
527
  License: MIT
528
528
  https://github.com/facebook/memlab#readme
@@ -553,7 +553,7 @@ SOFTWARE.
553
553
 
554
554
  ---
555
555
 
556
- ## @memlab/lens@2.0.4
556
+ ## @memlab/lens@2.0.5
557
557
 
558
558
  License: MIT
559
559
  https://github.com/facebook/memlab#readme