James M Snell

Looks like there are still some bugs to work out here with the failing CI... but even then, my preference would be to settle on https://github.com/cloudflare/workerd/pull/5449 first before landing any...

Two key concerns here.. 1. We're essentially opting out of v8 handling these at all at this point, which means we also opt out of any improvements they might make...

Coming off the heals of the P0 incident, we need to be careful about larger more complex changes for a bit. For this one, given how this API is used,...

An alternative way of doing this that *might* be better, is to add the following when the `opaqueTemplate` is created: ``` auto protoTemplate = v8::FunctionTemplate::New(ptr, &throwIllegalConstructor); protoTemplate->RemovePrototype(); opaqueTemplate->SetPrototypeProviderTemplate(protoTemplate); ``` This...

@erikcorry @dcarney-cf

In workerd, the console.log output ends up being routed through the nodejs_compat `util.inspect` and `util.format` methods, which does include some limited support for inspecting proxies. You'll find tho, that it...

I've opened an issue in Node.js about this: https://github.com/nodejs/node/issues/60964 The correct fix here would be to update the implementation of `util.inspect/util.format` to handle proxies more effectively.

The `showProxy` option shows details about the proxy itself and not the proxied object. It turns out that the behavior here is intentional. The `util.inspect`/`util/format` logic is avoiding triggering proxy...

Ok, in the interim.. a good solution here would be to have these Proxy objects implement the Node.js `util.inspect.custom` protocol. The Proxy objects themselves can have add an implementation of...

Update: Node.js will likely update it's handling here to output `Proxy {}` rather than just `{}` so at least it's a bit easier to understand the reasoning behing the empty...