Ron Buckton

It looks like it is set here: - https://github.com/nodejs/node/blob/main/lib/child_process.js#L245-L246 - https://github.com/nodejs/node/blob/main/lib/child_process.js#L890

@Lexicality: > what happens if I call foo()()? It depends on the behavior of `reader.read()`. In this example, `reader` would be closed as soon as `foo()` returns. Assuming `read()` requires...

> I'm a bit uneasy with the fact that it's allowed to create a Disposable without registering its dispose method to some kind of disposal scope, either with `using` on...

> ## 1. Leak diagnose > There should always be a retain path from the VM root to a living resource, or the teardown functions of that living resource. The...

> ## 1. Leak diagnose > I still think it's not an easy task to author safe `Disposable` resource even for engine developers. But that's easier for me, because I'm...

> It would probably be better if there's a standard utility to help non-engine developers to author "garbage-collectable" Disposables. It can reduce the complexity in writing custom `FinalizationRegistry` integrations if...

> I'm sure many people found that `register()` semantics confusing, but I understand why it was designed that way. Which is why I would like to see a simple interface...

I'm not clear on the issue the latest update to `reflect-metadata` caused, and I'd like to address it if possible. In the recent changes to `reflect-metadata` I was trying to...

> Any progress? A roadmap? What's current progress with the issue? Maybe it would be helpful to release a beta version of packages for testing. I'm still looking into this,...

I think I have discovered the cause. I should have a fix up for `reflect-metadata` shortly.