Open tlhunter opened 7 hours ago
It might fix deleting globals, but someone could still delete Array.prototype.push
and break undici? I am not sure what this would solve.
I don't have a strong opinion on this one. While we do not disrupt the current lib feature state.
Just be mindful that this might be a shift in the overall way we manage the building step.
I don't see what this solves
I'm going to try solving this on my own but I figured I'd create an issue to track it. Suggestions for making the change are appreciated!
This would solve...
I'm working on a side project and one of the things it does is to delete a bunch of globals, such as
global.WebAssembly
. This is fine for all of the internal Node.js modules since they make use of primordials which is essentially caching of JavaScript globals before user code runs.However the Undici bundled within Node.js throws an error.
Ideally it would be possible to delete most of the globals and Undici would be as stable as the other Node.js internal modules.
The implementation should look like...
Matteo suggested this change could be made as part of the build step when building Undici for Node.js. I think it can be solved with dependency injection.
WebAssembly
and any other globals that Undici depends on can be passed in. Perhaps the Undici code can be wrapped in a function like what Node.js does to inject__filename
into CJS files. Maybe like this:I have also considered...
I suppose I could not delete all the globals in my silly side project. And notably this is not an issue with real applications. And I don't think there is any security benefits as one could still mutate
WebAssembly
later even if Undici is using a version that is pulled from the global early on.Additional context
Here's a repro: