Feature request: export LoggerInterface in @aws-lambda-powertools/logger/types

[sandrokeil]

Expected Behavior

The LoggerInterface should be able to be imported, so I can decorate the logger with my own implementation.

import { LoggerInterface } from '@aws-lambda-powertools/logger/types';

Current Behavior

The current export of logger types is missing the LoggerInterface from Logger.d.ts. See

powertools-lambda-typescript/packages/logger/src/types/index.ts

Lines 9 to 18 in 72803e2

	export type {
	LogItemMessage,
	LogItemExtraInput,
	LambdaFunctionContext,
	UnformattedAttributes,
	PowertoolsLogData,
	ConstructorOptions,
	InjectLambdaContextOptions,
	CustomJsonReplacerFn,
	} from './Logger.js';

Code snippet

import { LoggerInterface } from '@aws-lambda-powertools/logger/types';

Steps to Reproduce

1. install powertools
2. try to import the LoggerInterface
3. TS2305 (no exported member) error should occur

Possible Solution

Export also LoggerInterface here

powertools-lambda-typescript/packages/logger/src/types/index.ts

Lines 9 to 18 in 72803e2

	export type {
	LogItemMessage,
	LogItemExtraInput,
	LambdaFunctionContext,
	UnformattedAttributes,
	PowertoolsLogData,
	ConstructorOptions,
	InjectLambdaContextOptions,
	CustomJsonReplacerFn,
	} from './Logger.js';

Powertools for AWS Lambda (TypeScript) version

latest

AWS Lambda function runtime

20.x

Packaging format used

npm

Execution logs

No response

[boring-cyborg]

Thanks for opening your first issue here! We'll come back to you as soon as we can.
In the meantime, check out the #typescript channel on our Powertools for AWS Lambda Discord: Invite link

[dreamorosi]

Hi @sandrokeil - thank you for opening the issue.

Could you please share a bit more about the use case for having the LoggerInterface exposed?

[sandrokeil]

@dreamorosi I want to create a logger class which implements the LoggerInterface. For this I want to use the decorator design pattern. I want to add the functionality of a so called FingersCrossed logger. If the LoggerInterface is exposed, I can implement any new functionality to the logging methods and don't need to change my code because I can reference the interface instead of the concrete implementation.

Any concerns about to export the LoggerInterface?

FingersCrosserLogger

A very interesting wrapper. It takes a handler (in my case the powertools logger) as a parameter and will accumulate log records of all levels until a record exceeds the defined severity level. At which point it delivers all records, including those of lower severity, to the handler it wraps. This means that until an error actually happens you will not see anything in your logs, but when it happens you will have the full information, including debug and info records. This provides you with all the information you need, but only when you need it.

[dreamorosi]

Hey, thanks for the additional info.

I don't have any major concern with exposing the interface, I'm only curious to learn how you'd use it.

I remember removing it from the exported types because I though having the actual class would be enough to extend the behavior, for example:

import { Logger } from "@aws-lambda-powertools/logger"

class MyLogger extends Logger {}

By using the interface with implements you'd have to replace the entirety of the Logger:

import type { LoggerInterface } from "@aws-lambda-powertools/logger/types"

class MyLogger implements LoggerInterface {}

Am I misunderstanding the intent?

I would really appreciate if you could share a concrete code example, even if it's pseudo code.

[dreamorosi]

Either way - based on our definition of bug this should be classified as a feature request, since it doesn't have an impact on the runtime behavior of the tool.

I'm going to change the type to Feature request and label as improvement.

[sandrokeil]

A public LoggerInterface would give the user more extensibility of the logger right? Yes, I have to implement all the methods from the LoggerInterface but it's just a pass through, except for the logging error level methods. Even a more smaller LoggerInterface with only the methods debug, info, warn, error and critical would be interesting and another interface for the others methods. But from my side the LoggerInterface can stay like it is.

IMHO: I would mark the Logger class as final and if a user needs other / enchanced functionality, they can just implement the LoggerInterface in their own class. So the pseudo code example below is a wrapper class which adds some functionality without overrding methods of the concrete implementation.

import type { LoggerInterface } from "@aws-lambda-powertools/logger/types"

export class MyEnchancedLogger implements LoggerInterface {
   constructor (
        private readonly logger: LoggerInterface
   ) {}

   private handle(...) {
      // more or less same logic like in PHPs FingersCrossed Logger
   }

   debug(input, ...extraInput): void {
       this.handle(input, extraInput);  
   }
   // same implementation for the other logging error level methods

  addContext(context): void {
    this.logger.addContext(context)
  }
  // same implementation for the rest of the LoggerInterface methods
}

[dreamorosi]

I see, thank you for taking the time to explain and share an example.

With this in mind, I think it can make sense to export the interface again.

I'm going to move onto your PR and leave any further comments there.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

This issue is now closed. Please be mindful that future comments are hard for our team to see.

If you need more assistance, please either tag a team member or open a new issue that references this one.

If you wish to keep having a conversation with other community members under this issue feel free to do so.

[github-actions]

This is now released under v2.6.0 version!