ehmicky

Yes, and also ensure the return value of `runFixture()` can be used for assertion purpose. For example, the return value of `runFixture()` in `@netlify/config` is currently a string (the config...

I am guessing this will allow log shipping plugins (e.g. redirect logs to specific services/servers). Is this the main purpose or do we have other business ideas behind this?

Thanks. So the main thing we want is to be able to redirect the logs to an external provider (our web UI, log shipping providers or alert systems)? Basically creating...

What about this: plugins can have a `log()` method that takes that object as input. This allow for plugins to do log shipping, alerts, etc. ```js module.exports = function myLogPlugin()...

If we want to catch all the logs, we don't need to monkey patch `console.log()`: we can just redirect the process stdout/stderr. Do we want to catch all the logs?...

I agree with @jlengstorf about avoiding monkey patching. I can see the convenience for the user to re-use `console.log()` since they already know those methods. However as @jlengstorf points out,...

I think what you are describing @DavidWells is how things are currently setup. At the moment, any output from a plugin (including from `console.log('thing happened')`) is shown in the build...

From an implementation standpoint, we are already redirecting `stdout` and `stderr` streams, so we could transform the normal log into a structured one directly inside the plugin process when user...

We just had a Slack discussion with @DavidWells and concluded that first-party and third-party outputs in plugins should not be distinguished. I.e. they should be presented the same way to...

@mraerino At the moment, we are just outputting `@netlify/build` logs to `stdout` (*and also `stderr`*). To summarize the current proposal: we're thinking of also outputting those in a structured file...