@aws-cdk/toolkit-lib: include NodejsFunction esbuild logs in ioHost notifications

[dreamorosi]

Describe the feature

When working with the new @aws-cdk/toolkit-lib and implementing a custom ioHost I'd like to have all the logs emitted by CDK included in the notifiy callback.

Right now this is not the case, and some logs like the one emitted by the esbuild bundling process are not included.

Use Case

When using the new toolkit customers can control all the notifications and apply complex filtering/workflows on them. Right now the logs emitted by the bundling are excluded from these notifications and end up directly to stdout.

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.1000.2

Environment details (OS name and version, etc.)

N/A

[mrgrain]

General idea is to mimic the existing Annotations class (see https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.Annotations.html), but with a focus on immediate output. The benefit here is that all messages will have a construct path attached to them and potentially even information about the construct FQN. This will allow upstream service to make informed decisions w.r.t. to output management.

We will want a reduced set of "levels" though. Probably just debug and info, since errors (and warns) are supposed to either a) fail immediately by throwing an exception or b) use Annotations to report errors and warnings into the Cloud Assembly if they are not blocking the rest of execution.

Internally the class should copy applicable features of IoMessage, i.e. be structured and have a level, time, and message. Maybe even a payload, but we can add this later if needed.

The class would come with a default implementation that just writes to stdout via console.log(). It could than allow setting a different implementation (needs to be a jsii compatible interface), so that a Toolkit lib user can provide a custom implementation (e.g. forwarding to an IoHost).

Eventually the default implementation could be configurable via ENV vars to not write a nice message to stdout, but to send the stringified json to a named file descriptor. This would improve passing of messages between app and Toolkit when a sub-process is used.