I think @sebmarkbage's point in #16115 and later #16087 is that we shouldn't play whack-a-mole with trying to clear as much as we can since it has a cost, and often masks the actual underlying issues. For each field clearing which "helps" we need to find a minimal reproducing case that demonstrates a leak.

No significant bundle size changes to report.

Generated by 🚫 dangerJS against 21fa5d2

In particular, the question would be, this fiber itself has been deleted. So if it’s still retain, what is holding onto to it? However in this case we actually have the very answer to that question in the comment above in the code. It’s an architectural quirks that leaves this node alive for a bit longer so we clear it.

I believe we actually do have a way to clear the right parent now so we might be able to do that instead.

@gaearon I'd also not play whack-a-mole, but as per Sebastian's above comment, the reason we have to do this to begin with is because of the architectural quirks. If we have a better solution, then I'm all ears. :)

I believe we actually do have a way to clear the right parent now so we might be able to do that instead.

@sebmarkbage What would that be? That sounds like a better approach.

When we add deleted fibers to the effect list. We know their parent’s work in progress. If we set the .return at that point then we’ll know which parent was the work in progress. Then we could do current.return.alternate.child = null here.

@sebmarkbage Makes sense. Shall we close this PR in favor of that approach? We can roll with this change until we land that change as a follow up.

Yea let’s land this first in case that other approach doesn’t work.