next-leak 0.1.3 → 0.2.0

package/dist/trend.d.ts

@@ -16,9 +16,44 @@ export type TrendResult = {
     source?: "heap" | "external";
 };
 export type TrendOptions = {
-    /** Minimum per-cycle growth (bytes) considered leak-like. Default: 256 KiB. */
+    /**
+     * Minimum per-cycle growth (bytes) considered leak-like. Defaults to the
+     * noise floor alone — callers that know how much traffic ran should pass
+     * `minGrowthFor(requestsPerCycle)` instead.
+     */
     minGrowthPerCycle?: number;
 };
+/**
+ * Smallest per-cycle growth distinguishable from measurement noise.
+ *
+ * This is a property of the *instrument*, not of the leak: post-GC samples
+ * jitter by roughly this much regardless of how much traffic ran, so no amount
+ * of load makes growth below it meaningful.
+ */
+export declare const MIN_GROWTH_NOISE_FLOOR: number;
+/**
+ * Growth rate that counts as leak-like, per 1000 requests.
+ *
+ * This is a property of the *leak*: a route that retains memory per request
+ * grows in proportion to the traffic it served, so the gate has to scale with
+ * it. 51.2 KiB is the rate that leaves the default profile (5000 requests per
+ * cycle) on exactly the 256 KiB gate this tool was validated against.
+ */
+export declare const MIN_GROWTH_PER_1000_REQUESTS: number;
+/**
+ * The gate a per-cycle delta must clear to count as growth.
+ *
+ * `max` rather than a sum, because the two terms bound different things: the
+ * floor is what the instrument can resolve, the rate is what the leak should
+ * produce. Below ~5000 requests per cycle the floor dominates and the run is
+ * noise-limited — which is a real limit of measuring less traffic, not a
+ * threshold that can be lowered.
+ *
+ * Without this, the verdict silently depended on `--requests`: the same route
+ * leaking 100 KiB per 1000 requests printed the same headline in every mode
+ * but came out `stable` at 2000 requests per cycle and `leak` at 5000.
+ */
+export declare function minGrowthFor(requestsPerCycle: number): number;
 /**
  * Classifies a series of post-GC retained-heap samples — baseline first, then
  * one sample per load cycle — as leaking or stable.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "next-leak",
-  "version": "0.1.3",
+  "version": "0.2.0",
   "description": "Find out whether your Next.js app actually leaks memory — how much, on which route, and whose fault it is.",
   "keywords": [
     "nextjs",
@@ -27,14 +27,15 @@
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",
   "files": [
-    "dist"
+    "dist",
+    "THIRD-PARTY-NOTICES.md"
   ],
   "engines": {
     "node": ">=22"
   },
   "packageManager": "pnpm@10.20.0",
   "scripts": {
-    "build": "tsup && tsc -p tsconfig.build.json",
+    "build": "tsup && tsc -p tsconfig.build.json && node scripts/generate-notices.mjs && node scripts/check-bundle.mjs",
     "dev": "tsup --watch",
     "test": "vitest run",
     "test:watch": "vitest",