flags@4.1.0

Minor Changes

• #385 201f9d5 Thanks @dferber90! - When applications call evaluate() or precompute() function from flags/next it now defers bulk evaluation to the underlying adapters in case those support it, or otherwise falls back to evaluating each flag individually.

  This speeds up evaluation for applications that need to evaluate multiple flags at once, as the runtime needs to handle fewer promises and more work is reused. In testing we have seen a 20x improvement when called with 100 flags.

  import { evaluate } from "flags/next";
  import { flagA, flagB } from "../flags";
  
  // pass a list of flags
  const [valueA, valueB] = await evaluate([flagA, flagB]);
  
  // pass an object
  const { a, b } = await evaluate({ a: flagA, b: flagB });

  Adapters can opt into bulk evaluation by implementing a bulkDecide method and setting a stable adapterId. When both are present, flag evaluation groups flags that share the same adapterId and identify source and invokes bulkDecide once per group instead of calling decide per flag. Flags without a bulk-capable adapter still resolve through the normal per-flag path inside evaluate() and still benefit from now reusing the shared per-request headers, cookies, and overrides reads.

  Tracing reflects this grouping. evaluate() (and therefore precompute()) now emits an evaluate span carrying a flagCount attribute. Within it, bulk-evaluated flags no longer emit an individual per-flag run span; instead each adapter group emits a single batch span (carrying the adapterId, the keys evaluated in the batch, and cachedCount/overrideCount/decidedCount attributes summarizing how the batch resolved) so per-flag instrumentation overhead is not reintroduced. Flags that fall back to the per-flag path continue to emit their own flag span as before.