I suppose it doesn't hurt to try it.
What I'm wondering is how we should export the classes on our part, and how the users import them in their applications.
How easy will it be to find the correct service/class?
Perhaps if we create the package on this repo without publishing, we can try it out :)

Possibly no documentation on pub.dev (mitigated by publishing our own documentation)

I can try to lobby for putting the package (and other similar large packages) on an exception list with longer timeouts (possibly only for the latest stable version).

Thanks for your input!

Let's experiment. As a first step, I'll modify the generation of the all_apis package with the layout I propose.
The way I see it, the imports will be:

import 'package:aws_client/s3/2006-03-01.dart';
import 'package:aws_client/apigateway/2018-11-29.dart';

The autocompletion will show all the available services at first and then the available versions.

I'd like to point out that aws-sdk-js V3 is generating(!) separate packages.

@Schwusch This is a very interesting discovery!!

I have experimented with the single package structure here: https://github.com/xvrh/aws_client/tree/master/aws_client/lib
I understand it's mainly a matter of taste and I don't want to push it in that direction if your are not convinced :-)

I have experimented with the single package structure

That looks incredibly clean I must admit!

I dug further into aws-sdk-js-v3, and apparently they use something called Smithy to generate the clients. Smithy is language agnostic, so they use smithy-typescript to generate the JS SDK. Which makes me wonder if it would be worth looking into making a smithy-dart to get all the juicy type information we need for Darts null-safety.

I would say, the only way of knowing if this is a viable alternative is to publish a package with all the services in it.
Since there is the option to mark a package discontinued and/or unlisted, I think it's worth a try.

It would probably solve the dependency problem I faced when resolving credentials with STS in #328.
There, it was problematic to use STS in the shared package, since STS in itself depends on the shared package.
If all code resided in the same package, perhaps that wouldn't be a problem.

If you feel like trying it out, I would say go for it :) If it's successful and appreciated, perhaps we can go in that direction instead.

makes me wonder if it would be worth looking into making a smithy-dart to get all the juicy type information

It seems @dnys1 is working on a smithy-dart implementation already.