Feature request: Silent mode for all testing environments

[jamesmhaley]

Use case

I'm a huge fan of the logger, thanks for all your hard work on it!! One side affect of it though is it can be super noisy when testing. It's useful to have the POWERTOOLS_DEV env variable, this is helpful. However, the problem with this is that there is no option of less noise, just silence.

I often debug with my IDE, but on occasion i'll add a console.log and find it useful to see that output. With my previous favourite logger (winston) you could silence within tests and that would stop the winston logger from outputting when explicitly silenced.

Solution/User Experience

It would be great to be able to set the logger to silent when a certain condition is met, like in a test or dev environment. This could be using NODE_ENV or another conditional.

A good solution would be to add an optional parameter of silent to the logger on invocation:

const logger = new Logger({
  silent: process.env.NODE_ENV === 'test',
  serviceName: 'AWS-SERVICE',
  persistentLogAttributes: {
    awsRegion: process.env.AWS_REGION || 'N/A',
  },
})

This would allow for console.log to still make it's way through to the terminal, while reducing the noise from Logger.

Alternative solutions

No response

Acknowledgment

• This feature request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Python, Java

[dreamorosi]

Hi @jamesmhaley thank you for opening this issue and for your support to the project!

I understand that you'd like to mute/silence the logs in certain situations i.e. debugging and/or testing but to further the discussion I'd like to better understand a couple of things:

• When using jest, you can silence logs both via the --silent flag or by providing a mock implementation to the console object itself (example). Would these be enough or do you see other cases in which these two don't cover your needs?
• You also mention the usage of console.log alongside Logger. Could you elaborate a little more on how you'd like the two to interact and in which situation?

Also, could you share an example of the docs from Winston where this behavior is shown? I think it'd help me better frame this feature request since I'm not familiar with that logger.

[jamesmhaley]

The --silent flag is helpful for muting all logs (including console.log), as is mocking console.log to have a custom implementation and in this way I could add the ability to turn on/off logs with a conditional, however both either result with no logs at all or mocking console.log still results with the Powertools logger logging out.

My suggestion is to mimic what winston does, as it would limit/suppress logs coming from Powertools logger but wouldn't require any env vars, the mocking of anything and would still allow use of console.log.

This is what the silent parameter in winston does: https://github.com/winstonjs/winston/blob/2489a3d13b20797d3dbc55d3daf560cf52c2e6a3/lib/winston/logger.js#L276

It's added as a param when you set up the logger, allow for a conditional to define it's state.
https://github.com/winstonjs/winston#creating-your-own-logger.

Both solutions currently in place are not perfect in my view, for example:

option	outcome
Env var and --silent	Stops all logging - including any ad-hoc console logs with console.log
Mocking console.log	Allows control over console.log, but does not silent Powertools logger
proposed silent param	Suppresses Powertools logger, leaves console.log untouched

I hope this makes sense, thanks again for all the hard work.

[jamesmhaley]

Again, to clarify my use-case:

My code uses Powertools logger to log out within my codebase. I log out a lot.

I write some tests, when running these I don't want the noise of the Powertools logs, so I would like to suppress them.

While writing my tests, to quickly check something like the data returned from a function call, I might add a console.log to output it's return data. I would want to see this in the console, so I can continue to write my tests, in particular the expect part. This would then be removed, so not to leave any console.logs in my code.

Obviously I can attach a debugger in my IDE, but when writing a quick test, this can be cumbersome and (as we all know) sometimes slow things down a bit.

I also don't like the idea of mocking console as it's something that in my view should be immutable, being a core part of JavaScript and could have unexpected side affects.

[dreamorosi]

Thank you for clarifying the use case, I now have a better understanding of what you're suggesting.

To begin, I want to contextualize the current Logger behavior and its interaction with jest specifically. Generally speaking, as stated in our tenets, we optimize first and foremost for running on Lambda. This allows us to make certain assumptions over the execution environment and the way people will use the libraries. With that said, developer experience is a close second and so I recognize that a feature like the one you're suggesting might have merits.

With the above in mind, Logger default behavior is to emit directly to stdout using a custom Console object (see code). The reason why we don't use the global console object is that the Lambda runtime applies its own patching to it so that it can append things like the request id and timestamp. In our case, we want to emit JSON-compliant logs only, so we couldn't use the global object and instead use our own (more context here).

In another feature request, customers have asked us to be able to disable logs when testing with jest. Jest also patches the global console object. This is what allows Jest to silence it (--silent) without requiring the user to change its code, and it's also the reason why the logs emitted by Logger were not silenced. To allow for this feature request, when customers explicitly tell us that they are running not on Lambda (or are developing) via the POWERTOOLS_DEV environment variable, we temporarily emit logs to the global console object, which allows jest or other modules/libraries to influence its behavior.

As a stop-gap solution, if you want to emit logs out of band, you could use this solution that I have tested and that works without having to mock the console while also having full control over your logs and have all others silenced:

Sample function that has logging in it (index.ts):

import { Logger, injectLambdaContext } from "@aws-lambda-powertools/logger";
import middy from "@middy/core";

const logger = new Logger({});

export const handler = middy(async () => {
  logger.info("Hello from the playground");
})
  .use(injectLambdaContext(logger));

Test file using jest (index.test.ts):

import { Console } from "console";
import { Context } from "aws-lambda";
import { handler } from "../lib/powertools-playground.function";

const console = new Console(process.stdout, process.stderr); // Create your own console object

describe("Sample Test", () => {
  test("does stuff", async () => {
    console.log('test'); // Use the newly created console object, this will always log regardless of Jest & Powertools flags/configs
    await handler({ test: "ok " }, {} as unknown as Context);
  });
});

Execute with export POWERTOOLS_DEV=true && jest --silent:

---

Before deciding on whether to introduce a new flag, or a new non-standard log level (i.e. SILENT), I think it'd be great to hear also from other customers who might have other use cases. I would also like to hear from the maintainers of the other runtimes to hear if they have ways of dealing with a similar requirement and/or have heard the same feature request from their users.

[saragerion]

I like Andrea's workaround, but I also do like the idea of a "silent" option.
To make it consistent with other powertools utilities, the silent logging behaviour could be enabled via for example an env variable POWERTOOLS_LOGS_ENABLED (defaults to true) or an enabled constructor parameter.

I don't have a strong opinion, happy to hear other people's perspectives.