perf(core-flows): index variants by id in cart line item preparation - #16233

Summary

What — prepareVariantsAndItemsWithPricesStep maps over the cart's line items and scans variantsData with .find() for every one of them:

const items = (inputItems ?? cart.items ?? []).map((item) => {
  ...
  const variant = variantsData.find((v) => v.id === item.variant_id)

variantsData is fetched for the variants those same items reference, so both sides grow together — the step is O(items × variants).

Why — this step is on the cart's hot path, not a one-off. It runs from:

How — index the variants by id once, then look up in O(1):

const variantsById = new Map<string, any>()
for (const variant of variantsData) {
  if (!variantsById.has(variant.id)) {
    variantsById.set(variant.id, variant)
  }
}
// ...
const variant = variantsById.get(item.variant_id!)

First match wins, so the result is identical to find. This is the same indexing pattern already used elsewhere in the cart flows for id matching.

Benchmark

Both variants copied verbatim from this file, output compared for equality before timing, median of 7 runs, one distinct variant per line item (the normal case):

The shape is what matters: doubling the line items roughly quadruples the current cost (7.1 ms → 27.6 ms from 1,000 to 2,000) while the indexed version stays linear.

Being straightforward about the scale: on a typical B2C cart of 5–20 lines this is microseconds and nobody will notice. It becomes real on large carts — bulk/B2B orders, imported carts, quote-style flows — where a single refresh can spend tens of milliseconds scanning. The change costs nothing at small sizes, so it is a floor-raiser rather than a fix for a reported incident.

Testing

Behaviour is unchanged: Map.get replaces a find over the same array with the same key, and the helper keeps first-occurrence-wins.

Honest about what I could and couldn't run locally:

• Type safety of the change — variantsData is any[] here, so the Map<string, any> and .get(item.variant_id!) introduce no new narrowing. I checked the changed file in isolation and it produces no type errors beyond the module-resolution ones that the same file already produces without my change.
• I could not run the monorepo typecheck or the integration suite locally (they need the full workspace build plus a Postgres instance), so CI is the first real run. Happy to iterate if anything goes red.
• No dedicated unit test exists for this step today. If you'd like one added as part of this PR, say the word and I'll add coverage for the mapping (variant found / not found / unpublished product / missing price) rather than for the lookup mechanism itself.

Added a changeset (@medusajs/core-flows patch).

Closes #16232