fix(logger): enable logging of arbitrary objects

[ghost]

Description of your changes

This PR relaxes the restrictions introduced by #614. In #565, we decided to restrict the additional logging data objects in their shape. It turned out, that this restriction prevents from logging of arbitrary objects, which is inconvenient.
In this PR, the type restrictions are removed, so it is now possible to specify any object as additional payload when calling the logger methods directly.

How to verify this change

• Run unit tests
• Run E2E tests
• Review docs and examples
• Try to log an arbitrary object by providing it as a property of a string-indexed object, e.g.

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

const logger = new Logger({ logLevel: 'DEBUG' });

export const handler = async (event) => {
  logger.debug('Lambda invoked', { details: { event } });
};

No compile time errors should be generated for the above example. The code should generate a valid log entry when executed.

Related issues, RFCs

#880

PR status

Is this ready for review?: YES
Is it a breaking change?: NO

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding changes to the examples
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published in downstream module
• The PR title follows the conventional commit semantics

Breaking change checklist

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[ghost]

@dreamorosi Ready for review

[dreamorosi]

Looking good, I'm going to run the integration tests on this branch: https://github.com/awslabs/aws-lambda-powertools-typescript/actions/runs/2347203386

[flochaz]

Can you add such object log in the e2e tests as well ?

[dreamorosi]

Run with the latest changes:

https://github.com/awslabs/aws-lambda-powertools-typescript/actions/runs/2351346144

[saragerion]

Thanks for opening this PR!
I have some questions about the choice of making the types more loose than they were before.
While making the types very loose (unknown is the most loose type we can use), we can still keep the existing types and allow for nested objects to be added anyway.
If there are some struggle with making the types work (I know they can be a pain :-)), I am happy to support/ help out myself with those and improve the existing types, rather than using unknown.

Also I would like us to cover a more diverse scenarios that include nested objects with different types next to the one where the object value is a string.

[dreamorosi]

E2E test is failing (link), it seems for a missing module (so before running the actual tests).

We need to investigate further.

[ghost]

@dreamorosi I haven't changed anything in the modules. In fact, we already had a similar issue with my first PR. The issue was caused by a faulty commit on main I based my branch on. Should I rebase my branch on the latest main again?

[dreamorosi]

@dreamorosi I haven't changed anything in the modules. In fact, we already had a similar issue with my first PR. The issue was caused by a faulty commit on main I based my branch on. Should I rebase my branch on the latest main again?

Yes, please, let's try to rebase.
And yes, I see that there are no changes in the modules.

[ghost]

@dreamorosi I double checked and can confirm that my branch is based on the latest main. In my fork, the tests are passing on my branch, please see the test run. Could you please check if something is going wrong on checkout/merge?

[ghost]

@saragerion Thanks for your comments! I replied directly in the threads. I also updated the tests to operate on complex and nested objects of various types.

To your main question: why unknown? I have not found any other way to allow logging of objects typed via arbitrary interfaces. Since we can't control how users define their interfaces (neither how AWS SDK does this), we would not be able to come up with a type definition that covers all those interfaces. A possible solution would be an empty interface, but it would actually mean unknown as well. Researching generics as suggested by @dreamorosi hasn't worked out either. If there's a trick in TypeScript I'm not aware of, please let me know!

unknown is very permissive, that is true. However, if we want to allow logging of arbitrary objects as stated in the issue, this is probably the way to go. Users could define some types we haven't thought of.

The latest E2E test run is passing.

[dreamorosi]

Thanks for the work on this topic, really appreciate it!