Last 12 weeks · 60 commits
2 of 6 standards met
Hello, I am writing a comprehensive integration/e2e test suite for my web application. What's the best way to mock flags sdk ? Do I write my own abstraction that would normally take flags sdk as source of truth, and only then overriding it in test files? Or do i override flags themselves? Constraints: should work on any test framework. Jest, Chai, Mocha, shouldn't matter which one.
Background removes a handler from the per-event but never deletes the (now-empty) from the Map. In long-lived emitter instances where / cycle repeatedly, retains one empty entry per distinct event name that was ever subscribed and then fully unsubscribed. The growth is bounded by the number of distinct event names (not the call count), and is an internal class, so this is memory hygiene rather than an unbounded leak. The path already guards against missing Map keys (), so removing the entry is semantically equivalent to leaving an empty Set behind. The method already has the symmetric discipline: it only inserts a Set when needed. This fix mirrors that pattern on the removal side. Source location line 20. Change 5 lines added, 1 modified. No changes to , , or the class shape. Test plan Added covering the basic cleanup contract plus 7 adversarial edge cases: Map entry removed when the last listener is removed Handler does not fire after Map entry preserved when other handlers remain on a never-registered event is a no-op Double- is idempotent Resubscribe via after a full creates a fresh Set Self-removing handler during does not throw Different event keys are independent after Map-entry removal is a no-op via the existing guard Full suite after the fix: 13 test files, 447 tests, all passing, zero regressions. Notes The leak is bounded (O(distinct event names), not O(call count)); the fix is memory hygiene matching the discipline already in . is unchanged: its existing guard makes a missing Map entry behaviourally equivalent to an empty Set.
Follow-up to the review request on : check whether the function returned by should anywhere, and add it where it is missing. Result: nothing was missing. Every path that needs request data already reads it, and the paths that do not read it must stay prerenderable. So this PR contains no behavior change — it documents the guarantee and locks it in with tests, since it is the kind of thing a future refactor can silently drop. The audit is "only necessary when dynamic rendering is required and common Request-time APIs are not used". Path by path: Adding to the App Router paths would also mean importing , which deliberately avoids at the top level so it keeps working in Pages Router, plus one more awaited promise per evaluation — for no change in behavior. What is in the PR Comments at each branch in , , , and the precomputed branch of , recording why is or is not appropriate there. Unit tests () asserting which paths touch / and which must not — including cache hits, overrides, bulk evaluation, precomputed reads, and Pages Router. e2e coverage in and : a new route rendering , a flag whose ignores the request and returns a new value on every evaluation. If the SDK were not reading the request, the page would be baked at build time. Next 15 build reports the route as , while stays . Next 16 (Cache Components) reports it as and streams the flag outside the static shell. Both suites assert two requests return different values. The Next 16 build is the sharpest check of the three. Replacing the flag with a bare in the same component fails the build with: Route "/tmp-counterfactual" used before accessing either uncached data (e.g. ) or Request data (e.g. , , , and ). With the flag, the build passes — Next.js itself confirms the SDK read Request data before ran. So if this guarantee ever regresses, stops building. Docs**: a "Dynamic rendering" section under in the API reference, and the same note in the flags-sdk skill, so nobody adds in front of a flag evaluation. Verification : 126 unit tests pass, clean. e2e: 7/7 pass. e2e: the new test passes. One pre-existing failure, , expects , which Next 16.2.12 does not emit for that route — reproduced on a pristine checkout, so it is unrelated to this change. clean on all touched files. No changeset: no published package changes behavior.
Repository: vercel/flags. Description: Flags SDK by Vercel Stars: 614, Forks: 83. Primary language: TypeScript. Languages: TypeScript (80.2%), MDX (18.6%), JavaScript (1%), CSS (0.1%), Svelte (0.1%). License: MIT. Homepage: https://flags-sdk.dev Latest release: flags@4.3.0 (6d ago). Open PRs: 22, open issues: 10. Last activity: 20h ago. Community health: 62%. Top contributors: dferber90, github-actions[bot], vincent-derks, luismeyer, AndyBitz, dependabot[bot], AAorris, christopherkindl, molebox, haydenbleasel and others.