deep: deleting a nested property does not notify (objProxyHandler lacks a deleteProperty trap)

[nj-reve]

In deep.ts, objProxyHandler implements get/has/ownKeys/set traps but no deleteProperty, so delete obj.nested.key on a deep-proxied object updates the target without notifying dependents — computeds/reactions tracking that key (or its parent's key collection via Object.keys/spread) stay stale until an unrelated tracked write. (Correction after further verification: this applies at every depth including the root — see the comment below; our initial 'root works' observation came from a wrapper of our own.)

Repro sketch:

const state = deepSignal({ nested: { a: 1, b: 2 } });
// effect/computed reading state.nested.a or Object.keys(state.nested)
delete state.nested.a; // no notification — stale reads
state.nested.b = 3;    // now the delete becomes visible too

We hit this in production code (a keyed override map inside a deep-signal draft: deleting a cleared key left a memoized computed stale). Fix that worked for us — a deleteProperty trap mirroring set's notification order:

deleteProperty(target, prop) {
  updateStorage(target, prop);
  dirtyCollection(target);
  return Reflect.deleteProperty(target, prop);
},

(With set's equals: () => false storage semantics, this also notifies on absent-key deletes, consistent with unchanged-value sets.) arrayProxyHandler may want the same treatment for completeness. Happy to send this as a PR if useful.

Tested against signal-utils 0.21.1.

[nj-reve]

Follow-up with a verified repro (signal-utils 0.21.1 + signal-polyfill, Signal.Computed-based, run against both the stock package and the package with the trap patch applied):

import { Signal } from "signal-polyfill";
import { deep } from "signal-utils/deep";

// per-key
const s = deep({ nested: { a: 1, b: 2 } });
const c = new Signal.Computed(() => s.nested["a"]);
c.get();              // 1
delete s.nested["a"];
c.get();              // BUG: still 1 (expected undefined)

// key collection
const k = new Signal.Computed(() => Object.keys(s.nested).length);
// same staleness after a delete

Results:

case	stock 0.21.1	with deleteProperty trap
nested per-key delete	stale	fixed
nested Object.keys delete	stale	fixed
root per-key delete	stale	fixed
root Object.keys delete	stale	fixed
set controls (per-key + new-key)	correct	correct

Two corrections/additions to my original report:

1. The bug is not nested-specific — the root proxy uses the same handler, so delete at any depth is silent. (My earlier "root works" note was an artifact of a local wrapper that adds its own trap.)
2. arrayProxyHandler also lacks a deleteProperty trap, so delete arr[i] is presumably affected too (mutating methods like splice/pop go through the dirty-method list and are fine); not covered by this repro.

The single trap addition from the original report fixes all four failing cases. Still happy to send it as a PR.

[NullVoxPopuli]

would be happy to receive a PR!