TS Type Breaking Changes

[MrArnoldPalmer]

Confirm by changing [ ] to [x] below to ensure that it's a bug:

• I've gone through Developer Guide and API reference
• I've checked AWS Forums and StackOverflow for answers
• I've searched for previous similar issues and didn't find any solution

Describe the bug
#3398 resulted in TS libraries consuming the aws-sdk to break if referencing the ConfigurationOptions type.

Is the issue in the browser/Node.js?
Node.js

If on Node.js, are you running this on AWS Lambda?
Yes (and also on users local machines)
Details of the browser/Node.js version
v12.18.2

SDK version number
v2.743.0

To Reproduce (observed behavior)
Create a typescript file w/ sdk dependency v1.739.0
Import ConfigurationOptions like so

import { ConfigurationOptions } from 'aws-sdk/lib/config'

Upgrade to sdk >v1.740.0
Import statement can no longer resolve ConfigurationOptions

Expected behavior
ConfigurationOptions is still available at lib/config entrypoint

Additional context
This is an issue within the aws-cdk. We use ConfigurationOptions in multiple places to expose sdk configuration options to the user in order for them to customize various behaviors.

It is also used within our custom resource provider framework runtime which runs inside the aws lambda runtime.

This poses a couple of issues for us. We can upgrade our code to point to aws-sdk/lib/config-base to reference this object, though if a user is running their code inside lambda we don't control the version of the sdk that is present. We have also considered not importing this type and instead writing our own interface that duplicates it. This obviously isn't ideal as if non-breaking changes are made to the interface in the future within aws-sdk-js, we would have to copy those changes in our code to make the feature available.

Since ConfigurationOptions is exposed on the constructor of the Config class, our assumption has been its okay to expose this type on our public API for use. Nested import paths can obviously be troublesome for refactoring, can ConfigurationOptions be exported from the top level along with other TS types exposed by the public API for library authors to reference? This still will break some of our users if they are using an old version of the sdk with a newer version of the cdk and vice-versa, but at least we could provide a fix path to upgrade one or the other.

[AllanZhengYP]

Hi @MrArnoldPalmer

Thank you for bringing this up.

can ConfigurationOptions be exported from the top level along with other TS types exposed by the public API for library authors to reference?

We can expose ConfigurationOptions in root level. I don't expect any breaking change will be introduced to the type. Any required configuration entry will definitely break users. In fact we should have done that before CDK importing the ConfigurationOptions from the path.

[MrArnoldPalmer]

Thanks @AllanFly120 ! I'm curious if just all interfaces/types that are exposed by exported APIs (whether as arguments, return values, properties, etc) should just be exported from the root to allow library authors the ability to rely on them going forward.

This obviously isn't needed for this specific problem, but it may make for a better experience for TS library authors building on top of the SDK.

[MrArnoldPalmer]

On that note, RetryDelayOptions is also used in the CDK https://github.com/aws/aws-cdk/blob/master/packages/@aws-cdk/aws-logs/lib/log-retention-provider/index.ts#L6 .

Can that be exported as well?

As far as I can see those are the only ones CDK is using, but I would imagine additional libraries are referencing others.

[AllanZhengYP]

We will re-evaluate all other interfaces later. The idea is still to minimize the surface area.