Will It Vibe?Unkeyed {#each} block
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
An {#each} with no (key) expression makes Svelte reconcile the list by position, so inserting, removing, or reordering items reuses the wrong DOM and component state: inputs, focus, and transitions attach to the wrong row. Heuristic: an index-keyed, append-only list is fine unkeyed.
Why it matters
An {#each} with no key makes Svelte match old and new items by position. When the list is reordered, filtered, or has items inserted or removed, Svelte reuses the DOM node that happened to sit at that index, so input values, focus, checkbox state, and transitions stay attached to the wrong row. This is a low-confidence check because a static, append-only list is fine unkeyed.
How to fix it
Add a key expression that uniquely identifies each item: {#each items as item (item.id)}. Use a stable identifier from your data, not the array index, since the index is exactly what causes the position-based bugs. If the list truly never reorders and only appends, you can leave it unkeyed, but keying it is cheap insurance.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo