aws-sdk as dev dependency

[henriqueguisasola]

Is there any special reason for aws-sdk being a direct dependecy? This increases my bundle size significally, since webpack is not able to exclude a dependecy of a dependecy properly, I've done some workarounds, but it would be much easier if aws-sdk was included as a devDependency or peerDependency

An example, my code:

import { APIGatewayEvent, Context, Callback } from 'aws-lambda'
import { TypeDynamo } from 'type-dynamo'

export const typeDynamo = new TypeDynamo({ region: process.env.REGION || 'us-east-1' })

export async function teste(event: APIGatewayEvent, context: Context, callback: Callback) {
  try {
    console.log(typeDynamo)
    callback(undefined, {})
  } catch (err) {
    callback(undefined, { err })
  }
}

This are my dependencies:

  "dependencies": {
    "type-dynamo": "^0.1.4"
  },
  "devDependencies": {
    "@types/aws-lambda": "8.10.1",
    "@types/aws-sdk": "2.7.0",
    "aws-sdk": "2.277.1",
    "serverless": "1.30.1",
    "serverless-offline": "3.25.6",
    "serverless-webpack": "5.1.1",
    "ts-loader": "4.2.0",
    "tslint": "5.11.0",
    "typescript": "2.9.2",
    "webpack": "4.5.0",
    "webpack-bundle-analyzer": "3.0.2",
    "webpack-node-externals": "1.7.2"
  },

And this is my bundle:

[lucasmafra]

Hi @henriqueguisasola,

TypeDynamo is a wrapper around AWS SDK and its implementation relies on that to provide all of its features, which means that it needs AWS SDK to run not only in development mode but also in production (and please note that, for a library, production code refers to the code generated after the build process that it's distributed through npm, regardless of any kind of application that the users of the library might employ it) and therefore it does not make sense to consider it as a dev dependency (if you take a look on the project dev dependencies you will see they are only there for development and test purposes and they are not necessary for the final after-build code to run, which is different from AWS SDK).

I'm aware that AWS SDK is not a lightweight library and maybe there's room for optimization (i.e TypeDynamo could depend only on the Dynamo-specific parts instead of the whole SDK) but is inevitable that the AWS SDK must be available in the Node.js application where the TypeDynamo is running on.

Regard your specific use case, I don't know what in your webpack configuration is leading your bundle to have multiple instances of aws-sdk, but webpack has built-in resources to avoid that kind of scenario such as Tree Shaking.

[lucasmafra]

Also, if you're running on Lambda, I recommend you to take a look at this TypeDynamo example application.

[henriqueguisasola]

I'm aware of the need of aws-sdk, also i'm aware that TypeDynamo is not a "AWS Lambda only" library, but it makes no sense to bundle it and deploy it to Lambda, since AWS exposes the aws-sdk for you inside their node environment, you are just duplicating code.

If you want a solution that embraces all environments, you can consider using aws-sdk as a peerDependency, this enforces the application to have aws-sdk installed(either as a devDependency or a regular dependency).

Regarding my specific use case, this is a pretty common problem with the serverless-webpack library(serverless-heaven/serverless-webpack#306), as I mentioned, there are some workarounds, but I have not found a final solution.

Also, I already have a project set, running on Lambda, that bundle I printed was generated using similar webpack/tsconfig files as the example application. I tried just replacing my config files with yours and i still get the same bundle sizes.