library bloats build output with more than 100M

[danikenan]

The library forces a huge penalty of 100M that are not needed at all or just partially.

aws-sdk ~= 90M

If used by a lambda, none of the libs needed. If used by a server, only the version v2/v3 needed.

Probably the correct way is to ensure it loads correctly for the version we need.

Also, the dependencies should probably be peerdependcies.

    "node_modules/typesafe-dynamodb": {
      "version": "0.2.6",
      "resolved": "https://registry.npmjs.org/typesafe-dynamodb/-/typesafe-dynamodb-0.2.6.tgz",
      "integrity": "sha512-zSlEZM3gJF1Hl6nMOAC5t7XAkGjdx5HZW2cGn9GNz4KABn+e+vHp65dShXZSKqHDVDGvUieELQ93gdVZPpKl5w==",
      "dependencies": {
        "@aws-sdk/client-dynamodb": "^3.429.0",
        "@aws-sdk/lib-dynamodb": "^3.429.0",
        "@aws-sdk/smithy-client": "^3.374.0",
        "@aws-sdk/types": "^3.428.0",
        "@aws-sdk/util-dynamodb": "^3.429.0",
        "@types/aws-lambda": "^8.10.124",
        "aws-sdk": "^2.1474.0"
      }
    },

[sam-goodwin]

Here's a PR setting the dependencies all as peer: #63

I think the assumption I made when I wrote this library is that it would be included as a devDependency, hence these are dependencies?

Are you including typesafe-dynamodb as a dep or dev-dep?

Do you think I should also make these dependencies optionalDependencies?

[danikenan]

Hi,

Thanks for your quick responses. Great job with the library!

Regarding your comments: if we only used types we could import type {Foo} from 'bar and leave bar as a devDependency.

I think this is still possible, and that many can probably use only parts of your library that only export types and thus still include the library as a devDependency.

However, when using parts that export code (constant vars, functions) such as *-item-commands, attribute-value you must include the code in the compiled output and/or reference it during runtime. So the library can no longer be a devDependency and its dependencies are pulled in as well.

With regard to the second issue: the inclusion of both V2 and V3 in the code. This is only of course important for those using the the code, not just types.

No doubt that in this case should not force library clients to import such a huge library like aws-sdk (at any version) if they do not need it. optionalDependencies are a good way to avoid it.

BTW - we have experience lots of conflicts between aws sdk libraries and sub libraries and came to realize that its best to use the version provided with the aws runtime (e.g lambda environment) and not bring your own sdk dependecies. This is any additional reason when it Its best to avoid this nailing versions with aws and/or requiring to include the sdk in your code.

[sam-goodwin]

Re-opening the issue since it was closed by previous PR. Want to check that there is not a lingering problem here.

However, when using parts that export code (constant vars, functions) such as *-item-commands, attribute-value you must include the code in the compiled output and/or reference it during runtime. So the library can no longer be a devDependency and its dependencies are pulled in as well.

Can you elaborate more? Is this solved by peer and optional dependencies? My understanding is that you can export values using types from a peer dependency. Is that what you mean?

Also, I have been considering dropping the aws-sdk dependency and simplifying the code to go all in on V3. Do you use V2? Considering it's deprecated by AWS, it might be worth removing it.

[rogerchi]

Go all in on V3 IMO