fix: breaking change to deployment config props

[MrArnoldPalmer]

Change all deploymentConfig static method implementations on
EcsDeploymentConfig, LambdaDeploymentConfig, and
ServerDeploymentConfig to return their corresponding specific
interfaces instead of IBaseDeploymentConfig. This reverts breaking
changes to Java users introduced in #22159

Fixes #22566

---

All Submissions:

• Have you followed the guidelines in our Contributing guide?

Adding new Unconventional Dependencies:

• This PR adds new unconventional dependencies following the process described here

New Features

• Have you added the new feature to an integration test?
  • Did you use yarn integ to deploy the infrastructure and generate the snapshot (i.e. yarn integ without --dry-run)?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

[MrArnoldPalmer]

@clareliguori I removed all of the "more specific" deployment config interfaces as part of fixing this, instead of re-implementing the deploymentConfig and fromDeploymentConfigNasme methods in all of the deployment config classes (with the more specific return types) since I couldn't think of any case off the top of my head where these interfaces may be needed with additional properties etc.

Additionally we should be able to add them back with additional optional properties in the future in a non-breaking way, just keeping them around seems dangerous as it opens us to this bug of structural interfaces are implemented somewhere where an explicit type is actually needed for Java compatibility.

[kaizencc]

Exempting tests. Our typescript tests are insufficient to test this anyhow. I will test this locally in java before merging this PR.

✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.

[MrArnoldPalmer]

@madeline-k pointed out a user explicitly importing and defining the more specific interfaces would be broken by this, but leaving them in feels like leaving the foot gun loaded.

import { IServerDeploymentConfig } from '';

const myThing: IServerDeploymentConfig { ... };

We may have to though, @kaizencc @corymhall what do you think?

[corymhall]

@madeline-k pointed out a user explicitly importing and defining the more specific interfaces would be broken by this, but leaving them in feels like leaving the foot gun loaded.

Yeah I think we probably should leave them in. If we mark them as deprecated thats probably good enough to prevent them from being used in the future.

[kaizencc]

I've looked over these and they seem reasonable from our changes, but want to highlight them just in case.

[MrArnoldPalmer]

Went back to keeping all of the interface types and instead of calling BaseDeploymentConfig.deploymentConfig from each implementor call a free floating function in utils.ts since overriding a protected method and changing the return type is not allowed by JSII. This should be non-breaking as BaseDeploymentConfig class is abstract.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 3b6bfde
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[kaizencc]

I tested this by running a java app against my local aws-cdk-lib with this change, and did not get an error. I also tested it against a normal aws-cdk-lib and did get the error. Putting my stamp of approval on this and shipping it.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).