Fix dangling staticNode reference on indirect subtree removal - #979

There are two issues here:

1. The cached static node is tied to a global root.

The helper checks whichever root most recently created <Static>. With two Ink instances using different stdout streams, removing <Static> from the first root after rendering one in the second leaves the first root's pointer stale. I reproduced stale output (first-history\nfirst-2), and further Yoga memory churn could still trigger the reported use-after-free.

Please derive the owning root from the host parent passed to removeChild, use the container directly for removeChildFromContainer, and add a two-root regression test.

2. CI is currently failing.

The new assertion is rejected by Prettier, so npm test exits before running the tests. Please format it and rerun CI.

One smaller concern: clearing yogaNode only on the removed top-level node does not invalidate descendants freed by freeRecursive(). I would either centralize that cleanup or remove this broader defense-in-depth mutation.

The test should also cover ancestor removal directly from the root, plus screen-reader and concurent rendering.

@sindresorhus Thanks for the thorough review — all points addressed in the latest push.

1. Owning root derived from arguments, not a global

clearStaticNodeIfContained now takes the root explicitly. It's derived from the removal hook's host parent (findRootNode(node) walks up to ink-root) rather than the module-global currentRootNode. removeChildFromContainer passes the container directly. So two instances on separate stdout streams no longer clobber each other's pointer.

Added a two-instance regression test that reproduces your first-history\nfirst-2 stale output and confirms it no longer replays.

2. CI / Prettier

Fixed the formatting that was aborting npm test before the suite ran.

3. The yogaNode cleanup — centralized instead of partial

You're right that nulling only the top node left descendants dangling. I removed that partial mutation and centralized it: freeYogaSubtree() in dom.ts frees the subtree's WASM memory and then nulls yogaNode on every DOM node in the removed subtree.

This targets the actual root cause — freeRecursive() leaves each JS wrapper truthy, defeating the ?.yogaNode guards throughout the codebase. Nulling the whole subtree makes those guards effective and closes the entire use-after-free class, not just the reported instance.

Clearing staticNode is still needed alongside it — otherwise the stale pointer suppresses the onStaticChange reset and replays stale static output (and the screen-reader path reads staticNode without a ?.yogaNode guard at all).

4. Additional test coverage

Added tests for: ancestor removal directly from the root (removeChildFromContainer path), the two-instance case above, screen-reader mode, and concurrent mode.

I found one issue:

The dirty flag is still set on the last root that created a <Static> node, instead of on the root being updated. With two Ink instances, render a <Static> in both, trigger a normal update in the first instance, then append an item to its <Static> during the same throttled window. The new item gets removed before the first root gets its immediate render, so it never reaches stdout.

This is reproducible with the default maxFps. The first instance keeps rendering its old static item and the new dynamic frame, but drops the newly added static item. Please derive the owning root from the updated node and add a regression test for updating <Static> in one instance after another instance has mounted <Static>. The existing two-instance test only covers ancestor removal, so it doesn’t excercise this update path.

Thanks — fixed in 8f6e998.

Dirty flag now derived from the updated node

The currentRootNode module-level global is removed entirely. All three call sites (commitUpdate, removeChild, removeChildFromContainer) now derive the owning root by walking parentNode up to the ink-root node, so isStaticDirty always lands on the root that owns the updated <Static> node.

Regression test added

New test covers the exact repro you described: render <Static> in two instances, then append to the first instance's <Static> after the second instance mounted one. Before the fix the appended item was dropped; the test now asserts it reaches stdout, and that the second instance's updates remain independent.