CI: https://ci.nodejs.org/job/node-test-pull-request/38490/

CI: https://ci.nodejs.org/job/node-test-pull-request/38492/

Can Electron modify the options object directly? This PR would currently be adding an undocumented, untested, non-public pair of functions, which I don’t think is something we’d want to land.

I'd be ok with this if a reasonable test can be added for it.

@jasnell I would still argue that unused private APIs are things that should be removed from our source code, not added.

Unused by whom? Electron would be using these. Perhaps finding a way of making them a part of the supported embedder API would be a better approach.

Perhaps finding a way of making them a part of the supported embedder API would be a better approach.

Yes, exactly the point.

@addaleax how would you envision that differently to what's here now? I added this to approximately follow the approach I took in #35024 which was similarly embedder-facing and wasn't sure what alternate approaches might be preferable 🤔

how would you envision that differently to what's here now?

I guess my first question would still be whether Electron can modify the options object directly… that’s also not something in the public API, but I would expect it to be fairly consistent.

In the long run, it would probably be nice if there was a generic way to get/set options through the embedder API?

I added this to approximately follow the approach I took in #35024 which was similarly embedder-facing and wasn't sure what alternate approaches might be preferable thinking

I didn’t notice that PR, sorry – I’d revert it, tbh. I don’t think Electron gains anything from that change or from this one in its current state.

Closing in favor of modifying the options object directly.