Dev diagnostics: attribution cost checks (WIDE_SCOPE_DEPS at 30) now on by default via performance tracks, and count HMR plumbing

Start with packages/signals/src/core/attribution.ts, especially checkDepWidth and the wideDeps threshold, then read packages/solid/src/refresh/index.ts to trace the _plumbing memos. Compare that behavior with the performance-tracks attribution holder and decide which documented diagnostic behavior should apply. Done means the default dev session no longer produces an unintended warning, or the intended default and coverage are clearly established.

Summary

Since @solidjs/vite-plugin loads the Chrome Performance panel tracks in every dev session (next.47), the attribution engine is enabled by default in dev with its cost checks on. WIDE_SCOPE_DEPS — designed as an opt-in close-up lens at a threshold of 30 — now fires on ordinary code. The first case found isn't even user code: it counts the HMR wrapper's plumbing memos.

Reproduction

examples/hackernews-spa on @solidjs/[email protected], pnpm dev, load any 30-story feed page:

[WIDE_SCOPE_DEPS] effect "effect" is subscribed to 30 sources — it re-runs when any of them change.
Narrow its reads or split it into smaller memos. Sources: anonymous, anonymous, anonymous, …
  in <Document> › body.children › <App> › <Router> › … › <Stories> › effect › effect

The same app on plugin next.35 is silent (attribution was not enabled there).

What the 30 sources are

<For> itself tracks only the list (mapArray returns one accessor). The sources come from dev-only HMR:

1. In dev, $$component (solid-js/refresh) wraps every component instance, and HMRComp returns a createMemo(..., { _plumbing: true, transparent: true }) instead of the component's node (packages/solid/src/refresh/index.ts).
2. Each of the 30 <Story> rows is therefore a memo accessor, not an <li>.
3. The <For> sits in an insert with no name (hence effect › effect); its inner effect normalizes the mapped array, calling every function it finds under tracking → 30 plumbing memos.

In production Story returns its <li> and the insert tracks nothing per row. Tracking the memos is correct (the insert must follow them for a hot swap), but the wrapper's comment says plumbing memos are "unrecorded by the attribution engine", while checkDepWidth (packages/signals/src/core/attribution.ts) counts every dep, plumbing included.

Why it now shows by default

• The threshold never moved: wideDeps: 30 since the prototype (1386b9c31) and #3018 (3d2c21fe8), whose docs describe it as: "fires at a much lower threshold, but only while the attribution engine is enabled — it names the offending sources. HUGE_FAN_IN is the always-on backstop for the pathological case." HUGE_FAN_IN is GRAPH_SIZE_WARN_AT = 2000 (packages/signals/src/core/dev.ts).
• Performance tracks (#3580) take a hold with attribution.enable({ log: false, ...options.attribution }) and leave checks at the engine default (true); the adapter's own comment says to pass checks: false "for records only".
• @solidjs/vite-plugin next.47 imports the tracks module into every dev client entry (performanceTracks defaults on under serve).

Net effect: the opt-in lens became an always-on default-dev warning at a threshold calibrated for someone already looking.

Options (not mutually exclusive)

1. Tracks don't take the cost checks — the performance-tracks hold passes checks: false (records only, as its comment describes). WIDE_SCOPE_DEPS stays the opt-in lens it was designed as. Behavior change: all five cost checks (hotRuns, hotTime, wideDeps, unstableMemos, wideWrites) go quiet in default dev unless another holder asks for them.
2. Raise the default (≈1000) if the cost checks are meant to be default-on now. Then WIDE_SCOPE_DEPS and HUGE_FAN_IN (2000, always on) largely overlap and the case for two separate checks weakens.
3. Exclude _plumbing sources from the width count regardless of the threshold — HMR plumbing shouldn't count against a scope, at any size. Worth auditing the other per-source attribution checks for the same gap.

All three are dev-diagnostics behavior changes (@solidjs/signals, @solidjs/web).

Possibly related (unverified)

examples/chat on the same plugin logs repeated ABANDONED_FLIGHTS ("computed" abandoned 3 flights in 1000ms) under <App> › <For> › <Loading> › children › <Reply> › computed › computed while a reply streams — each streamed chunk supersedes the previous pending value. <Reply> also goes through the HMR wrapper, so this may be the same plumbing blind spot or a separate calibration problem for streamed sources; not traced yet.