Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#3,739 1 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, typescript
Lĩnh vực
devtools, performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
36.1k
Fork
1.1k
Merge trung bình
13 giờ 13 phút
Pull request đã merge (30 ngày)
306

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của solidjs/solid

Tất cả issue của solidjs/solid

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.