powertools-lambda-typescript: Bug: unable to build with `tsc` when not using `@middy/core`

Hi @ValeryShvyndzikau, that’s great to hear you’ll be adopting the utilities. I just want to acknowledge that I read your message, I will be talking about this issue with @dreamorosi this week and we’ll get back to you with a more concrete answer by the end of the week.

To build on Sara’s previous comment, currently the packages are exported like so:

Note From here onwards I talk about Tracer but the same applies to Metrics and Logger

File packages/tracer/src/index.ts

export * from './helpers';
export * from './Tracer';
export * from './TracerInterface';
export * from './middleware/middy';

which once built and packaged allows consumers to import like:

import { Tracer, captureLambdaHandler } from "@aws-lambda-powertools/tracer";

or, if not using the Middy middleware:

import { Tracer } from "@aws-lambda-powertools/tracer";

As reported by the discussion in this thread, when bundling with tsc the compiler throws an error because it expects @middy/core as dependency. This doesn’t happen when using esbuild.

In order to fix this, it seems that we need to change the main entry point like so:

export * from './helpers';
export * from './Tracer';
export * from './TracerInterface';
-- export * from './middleware/middy';

This would allow everyone to still import the main Tracer class like before:

import { Tracer } from "@aws-lambda-powertools/tracer";

but, most notably, it’ll require those who use the middleware to change their imports to:

import { captureLambdaHandler } from "@aws-lambda-powertools/tracer/middleware";

Now, this would solve the issue in question, but it would also constitute a breaking change, which will require us to do a major release to v2.0.0. We need to discuss how this fits with our roadmap.

Thanks again @rreddypally for reporting this bug and providing a repo to reproduce the issue.

Upon a bit of investigation playing around with the repo I found out why the compiler is complaining when folks are not importing the middleware file in their codebases I came to a similar conclusion reached in a PR that was opened before creating this issue.
This happens because in the Tracer’s declaration file located in ./node_modules/@aws-lambda-powertools/tracer/lib/Tracer.d.ts we are importing the TracerInterface via a wildcard import, instead of importing the TracerInterface file specifically. As a consequence, all the content of ./node_modules/@aws-lambda-powertools/tracer/lib/index.d.ts is loaded and checked by the compiler:

export * from './helpers';
export * from './Tracer';
export * from './TracerInterface';
export * from './middleware/middy';
//# sourceMappingURL=index.d.ts.map

Notice the 4th line, which is causing an error.

Steps to reproduce:

• Clone the repo: https://github.com/rreddypally/tracer-demo
• Run head -2 ./node_modules/@aws-lambda-powertools/tracer/lib/Tracer.d.ts and notice the TracerInterface import
• Run npm run build and notice the error thrown
• In your local codebase, edit the file ./node_modules/@aws-lambda-powertools/tracer/lib/Tracer.d.ts from this: import { TracerInterface } from '.'; to this: import { TracerInterface } from './TracerInterface';
• Run npm run build and notice the lack of errors;

The fix for this issue is make sure that the middy middleware file is not imported elsewhere like other folders and files, by removing it from example from the index file imports. Applicable to all other packages too.