1219 was kind of ugly: it serialized the `serialize` function, parsed it in the comptime context, and then ran it there, so that it could have access to the context's globals.

This PR takes what I think is a cleaner approach: run the serialize in our usual context, but give it access to the comptime context's globalThis and check for matching objects from either globalThis.

In both approaches we have to copy globals over to comptime context, because new contexts don't get the usual Node builtins, such as URL. (See https://github.com/nodejs/node/issues/28823) I'm now doing this in the way that node:repl does, which is better: it gives the comptime context access to important Node globals like fetch, atob, process, etc. This also restores Node's global which seems to be global to all modules, whereas globalThis is local to the module, which makes sense and enables some magic interactions.

// one.js
global.x = 5
require('./two.js')
// two.js
console.log(global.x)  // prints 5

DanielXMoore / Civet

Use context's globals instead of serializing there #1220

1219 was kind of ugly: it serialized the `serialize` function, parsed it in the comptime context, and then ran it there, so that it could have access to the context's globals.

DanielXMoore / Civet

Use context's globals instead of serializing there #1220

1219 was kind of ugly: it serialized the serialize function, parsed it in the comptime context, and then ran it there, so that it could have access to the context's globals.

1219 was kind of ugly: it serialized the `serialize` function, parsed it in the comptime context, and then ran it there, so that it could have access to the context's globals.