Release 2.x.x milestone

[saragerion]

I see a number of great ideas and improvements suggested by our community recently, together with a backlog other improvement points collected over time.

While I am enthusiastic about many of them, my concern is that some are (or might be) breaking changes and that of course wouldn't be ideal to release without a major version upgrade.

If our roadmap and priorities allow it, I'd like us to consider a 2.x.x release soon.

[dreamorosi]

An item that comes to mind is the structure of the exports of the core utilities: Tracer, Logger, Metrics.

Currently all core utilities are exported similar to this:

export * from './Tracer';
export * from './middleware';

This means that users who don't use Middy middleware, are still importing the code under ./middleware and given that this code expects @middy/core as dependency, those users either have to manually tree-shake the code, or risk having a compile error at built time due to a missing dependency.

When using esbuild this is done automatically, but when using tsc, this causes issues similar to the ones reported here: #1068.

To get around the issue and avoid a breaking change by modifying the exports, in #1225 we have temporarily brought the @middy/core types in the codebase.

We should revisit this decision while working on a 2.x.x release, and with the freedom to change the exports, so that we can go back to using the types from Middy and remove them from our codebase.

[dreamorosi]

An additional change that I'd like to do in v2 is to move up the exports one level for these three utilities.

Currently if I want to import anything other than the default exports present in index.ts, I need to import using the full path, for example, for types it's:

import type { LogLevel } from '@aws-lambda-powertools/logger/lib/types';
``
There's no reason why that `lib` should be there and we should instead flatten the structure to something like `@aws-lambda-powertools/logger/types`.

[dreamorosi]

Another item related to export would be to drop the undocumented createLogger and createTracer that are currently exported in Logger and Tracer.

[lkhari]

Another ideal feature for v2 would be correlation Id as mentioned in #129 .

An upgrade to 2.x.x will allow for breaking changes, which would be the perfect time to explore this story. The story will most likely make a breaking change to the logger. But it will add a lot of value to developers who operate at scale or to systems with a lot of microservices talking to each other, which could add more interest to these packages.

[dreamorosi]

Another item that could be addressed is extending the behavior of the formatAttributes method that is part of LogFormatter, to more closely align with the implementation in Python.

Currently the method allows to format only certain attributes of a log entry: the standard attributes and context-related ones (when present).

We have a feature request (#1261) that suggests allowing to format also other attributes of a log (i.e. extraInput and persistent attributes), however allowing the feature would result in a breaking change.

See this comment/discussion for a proposal of the feature.

[dreamorosi]

Still related to Logger, we should consider revisiting some of the interface/type names to make them more specific and explicit about what they are: i.e. ClassThatLogs and ConstructorOptions.

[dreamorosi]

Related to Metrics, we should review the types, interfaces, and their names exposed by Metrics and make sure they are:

• all needed (i.e. maybe some of them don't need to be exported)
• follow best practices in terms of naming and separation of concerns
• don't mix types and objects: i.e. things like MetricUnits or Emf are not really types but are currently treated as such

This was discussed as part of #1373 in this comment (point 1).

[dreamorosi]

We have created a new RFC issue to track the progress of the new release: #1714.

I'll close this discussion in favor of continuing it under the RFC.