Expose console primitives to Workers

[jfancher]

This is a probably a pretty niche use case, but maybe there's some useful general feature to arise from it.

I have the following situation:

• I am running some code in a Worker
• I would like to capture console output that happens in the worker (exactly as it would be written to stdout/stderr, ideally)
• The worker loads user-provided and semi-trusted code, so I don't want to give it Deno privileges

I tried to copy/paste the guts of the console implementation, but in addition to being quite complex, it's not possible to replicate fully without some internal hooks, notably to inspect Promise values (and maybe other stuff).

Other approaches I tried or considered:

• The low-tech solution of just consuming the Deno process's output stream, but once there's more than one such worker it's not possible to distinguish between them.
• A convoluted implementation that uses message passing to the main thread to call Deno.inspect, but there's no guarantee that logged objects can be transferred over the boundary.

I got stuck at this point, and ended up forking Deno to solve this. (I added a runtime/js script that exports the Console class, and do console = new Console(myInterceptorFunc) in the Worker module). This was quite a simple change and ended up with exactly the behavior I want, but naturally I'd rather not have to maintain a fork.

Would any of these features be considered for Deno (in order of how useful they'd be to me)?

• Exposing the Console class constructor to workers somehow
• Providing a CLI option that allows injecting scripts while the global context is being set up (so I could do what my fork does without rebuilding the binary)
• Providing an option in the Worker constructor to redirect its output/error streams
• Making it possible to give a worker access to Deno.inspect but nothing else (maybe #8174 implies this, but it's not clear to me if it goes far enough)

Open to any other alternatives that achieve the same result as well!

[kitsonk]

I am not a fan of this suggestion, as it leaks a lot of "private" non-web standard stuff, no matter which way you look at it, and it would dramatically increase the "contracted" API surface.

I had a similar problem of wanting to "sandbox" a workers console output and did this: https://github.com/kitsonk/dectyl/blob/main/runtime/console.ts along with this https://github.com/kitsonk/dectyl/blob/main/runtime/inspect.ts. It is effectively a re-implentation of the Deno runtime code for console and inspect and then post a message back to the main worker for additional processing: https://github.com/kitsonk/dectyl/blob/main/runtime/main.ts#L612-L618

[pawelmhm]

This is a probably a pretty niche use case

It is probably not that niche, because users asking about this on StackOverflow https://stackoverflow.com/questions/64362869/how-to-pipe-stdout-stderr-to-file-from-worker-in-deno and I have same problem and @kitsonk also faces the need to do this.

If you consider workers are good idea for running code you don't really fully trust it seems logical you don't want to have standard output or error of this process in your parent process logs.

Providing an option in the Worker constructor to redirect its output/error streams

:+1:

Something like this could be nice

const worker = new Worker("./worker.ts", {
  type: "module",
  deno: true,
  stdout: file.rid,
  stderr: file.rid
});

non-web standard stuf

It is certainly not typical web standard stuff, but maybe it could be done with web platform in mind, e.g. by providing stderr or stdout via transferable streams? https://github.com/whatwg/streams/blob/main/transferable-streams-explainer.md?

You could then create a worker with stdin, stdout and stderr set to some web streams

[bartlomieju]

We discussed this during our team meeting and we're feeling we should add Console constructor to console object, that would allow users to override the global console instance and direct logs anywhere user wishes.