Trim production dependencies

Is your feature request related to a problem? Please describe.

I’m hoping to switch to aws-sdk-js-v3 for its modularity, in the hope that the package sizes are smaller than v2, but I notice a lot of dependencies being installed that don’t seem necessary at runtime, which actually make it quite a large npm install.

For example, middleware-retry has as production dependencies:

• react-native-get-random-values

This only seems to be needed for very specific environments (react native) and so users who need it should install it as a peer dependency, but to have everyone install it (and therefore have to maintain it, and patch it if there are security issues, etc) seems an overreach.

<del> - `@aws-sdk/types`

This seems to a module made up of TS and empty *.js files. My guess is it should be a dev dependency only for typescript, and possibly reworked so the js files aren’t included at all.

</del>

(addressed in #1649)

<del> - `tslib`

This should only be used at dev time too – for bundling. I doubt that this is used during runtime (but could be wrong?)

</del>

Describe the solution you’d like

Ensure that each module only has the very minimum that it needs in terms of production (non-dev) dependencies.

Additional context

One HUGE advantage of aws-sdk v2 as it stands right now is that it has very few dependencies – this means that users don’t end up having to constantly patch sub-sub-dependencies of modules they don’t even use. It would be great if v3 could also carry this philosophy over, as well as its goal of providing small individual modules for tree shaking

Right now I’m quite surprised at the size. Eg, installing just a single client, eg @aws-sdk/client-ssm, results in 102 packages being installed (half of which seem to be non-AWS modules) and a 19.2MB node_modules. That’s almost half the size of the entire aws-sdk v2 for just one client – and a lot more packages to potentially patch and maintain

[trivikr]

Also, you can’t just go around to every react-native polyfill library and ask them to make this change - all it takes it for one not to do it, and this is where you’ll end up.

That’s right. I’ve closed the issues with react-native polyfills repos:

• https://github.com/LinusU/react-native-get-random-values/issues/27
• https://github.com/charpeni/react-native-url-polyfill/issues/269

Decision taken by the team during post-scrum on 3/26: Make react-native polyfills as optional peer dependencies in aws-sdk-js-v3.

Question yet to be answered:

• Should aws-sdk-js-v3 call react-native polyfills in the code, or should they be delegated to consumers which consume aws-sdk-js-v3 in react-native environments? The team is inclined to delegate the requirement to consumers.
• If react-native polyfills are to be called from the code, should they be called from .native.ts files? This way, an error would be thrown in React Native environments is aws-sdk-js-v3 customer on react-native platform doesn’t have polyfills installed.

[mhart]

I’d love some feedback here – I keep seeing @aws-sdk/types being added as a production dependency to new modules being added to this project, and I really don’t think it should be