use-deep-compare-effect

Fixes #69. One-line diff (plus the dependency entry): has two defects that surface through this hook — greedy-matching false negatives on equal Maps/Sets (effect re-runs when deps didn't change) and a RangeError crash on any cyclic value in deps. Repros in the linked issue. Why this is safe This repo's own suite: green, unchanged — 8/8 tests, 2/2 snapshots (same as with ; also ~equal runtime). Typecheck deltas: none (pre-existing noise identical on both sides). Behavioral compatibility, verified not asserted: an explicit feature battery plus 8,000-pair differential fuzz against shows zero disagreements outside 's pinned defect classes (audit source). Every difference is crashing or answering provably wrong — never silent semantic drift. Independently checkable: isoequal ships a 120-line reference implementation you can read in one sitting; the optimized engine is differentially tested against it and against a brute-force isomorphism oracle on thousands of seeded random graphs. Supply-chain neutral: zero runtime dependencies (same as ), MIT, dual ESM/CJS, types included. Cost, stated honestly compares tiny flat objects in ~0.7µs vs 's ~0.16µs (it tracks object identity to get cycles and aliasing right — that bookkeeping is the fix). For a hook that runs per-render on deps arrays, this is noise; the crash and the spurious re-runs are not. Summary by CodeRabbit Bug Fixes** Improved the reliability of deep comparison used when determining whether memoized values need to be recalculated.

dependency: spurious effect re-runs on equal deps, and a crash on cyclic values Two reproducible defects in the dependency surface directly through : 1. Spurious re-runs: returns for genuinely equal values. Its Map/Set matching is greedy (first structurally-equal key wins, no backtracking), so equal collections with duplicate-shaped keys compare unequal: Any component passing such a value in deps gets its effect re-run on every render despite deps being deeply equal — the exact failure mode this hook exists to prevent. 2. Crash: any cyclic value in deps throws . Cyclic references occur in real state (normalized stores with parent links, DOM-adjacent data): Both are pinned with executable repros in isoequal's compatibility audit, together with an 8,000-pair differential fuzz showing agreement with everywhere outside its defect classes. I have a PR ready that swaps the dependency for (zero runtime deps, dual ESM/CJS): this package's own test suite passes unchanged (8/8, 2/2 snapshots), and both defects above become correct behavior. Happy to adjust scope however you prefer — including just documenting the limitation if you'd rather not touch deps in maintenance mode.

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency The fully-formed ref of the branch or tag that triggered the workflow run. For workflows triggered by , this is the branch or tag ref that was pushed. For workflows triggered by , this is the pull request merge branch. For workflows triggered by , this is the release tag created. For other triggers, this is the branch or tag ref that triggered the workflow run. This is only set if a branch or tag is available for the event type. The ref given is fully-formed, meaning that for branches the format is , for pull requests it is , and for tags it is . For example, . https://docs.github.com/en/actions/learn-github-actions/contexts#github-context