Installing with "^4.0.1" vs "4.0.1"

[sbusch99]

What are the steps to reproduce this issue?

For node 16.14.2, npm 8.12.1
In package.json

`"@honeybadger-io/js": "^4.0.1",`

rm -rf package-lock.json node_modules
npm i
npm run start (from angular)

What happens?

Error: node_modules/@honeybadger-io/js/dist/server/aws_lambda.d.ts:1:49 - error TS2307: Cannot find module 'aws-lambda' or its corresponding type declarations.

1 import type { Handler, Callback, Context } from 'aws-lambda';
                                                  ~~~~~~~~~~~~




** Angular Live Development Server is listening on localhost:4200, open your browser on https://localhost:4200/ **


✖ Failed to compile.
✔ Browser application bundle generation complete.

15 unchanged chunks

Build at: 2022-08-25T18:28:50.189Z - Hash: 7a248b080babd099 - Time: 2325ms

Error: node_modules/@honeybadger-io/js/dist/server/aws_lambda.d.ts:1:49 - error TS2307: Cannot find module 'aws-lambda' or its corresponding type declarations.

1 import type { Handler, Callback, Context } from 'aws-lambda';

What versions are you using?

Operating System: …
Package Version: node 16.14.2, node 8.12.1
Browser Version: …

Comments

If I change to below it works. With ^4.0.1, 4.1.0 is installed

"@honeybadger-io/js": "4.0.1",

[subzero10]

@joshuap This happens because we are using aws-lambda type definitions but we do not have aws-lambda as a dependency in the package.json file. This is because we just define the types for our lambdaHandler wrapper with the help of @types/aws-lambda, nothing else.

This could be solved in 2 ways:

1. Ask people to set skipLibCheck: true in their tsconfig.json file, which tells Typescript to skip .d.ts files. By the way, this value is set by default with npx tsc --init. I don't like it though.
2. Add types/aws-lambda as a dependency. Not the best solution, but it will work for now.

Ideally, here's how it should be:

• we publish a @honeybadger-io/aws-lambda (or any suitable name for our lambdaHandler) package with peer dependency on aws-lambda
• we move the AWS Lambda code in this package, eliminating the need for any reference to aws-lambda type definitions in the @honeybadger-io/js package

That's why we went for the monorepo approach: to be able to create more isolated packages and manage them easily.

[joshuap]

Ideally, here's how it should be:

• we publish a @honeybadger-io/aws-lambda (or any suitable name for our lambdaHandler) package with peer dependency on aws-lambda
• we move the AWS Lambda code in this package, eliminating the need for any reference to aws-lambda type definitions in the @honeybadger-io/js package

That's why we went for the monorepo approach: to be able to create more isolated packages and manage them easily.

I like it 👍

[subzero10]

@sbusch99 This should be fixed with v4.1.2!