Fix dependency versioning of AWS-vended packages #388
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
smithy-aws-typescript-codegen bundles a properties file that has the version of every client and library that the JS SDK vends. This essentially ties that set of versions to the published version of the smithy-aws-typescript-codegen package. Instead of hardcoding specific versions of AWS clients and libraries, this change parses that file if smithy-aws-typescript-codegen is also on the classpath, so that we can use compatible versions of these packages when we generate package.json. If smithy-aws-typescript-codegen is not on the classpath we fall back to "latest" for these packages.
JordonPhillips
approved these changes
Jul 21, 2021
|
|
||
| private SdkVersion() {} | ||
| private static String getVersion(String packageName) { | ||
| return VERSIONS.getOrDefault(packageName, "latest"); |
There was a problem hiding this comment.
This is very unfortunate as it essentially means you always need to have a dependency on the aws generator even if you're not using any aws stuff. That's probably still better than the current situation though
There was a problem hiding this comment.
Yeah I can't think of another alternative. Though hopefully if you're not using an AWS protocol, the chance we break you with a backwards-incompatible change to one of the few utility packages we rely on is low...
AllanZhengYP
approved these changes
Jul 21, 2021
srchase
pushed a commit
to srchase/smithy-typescript
that referenced
this pull request
Mar 17, 2023
smithy-aws-typescript-codegen bundles a properties file that has the version of every client and library that the JS SDK vends. This essentially ties that set of versions to the published version of the smithy-aws-typescript-codegen package. Instead of hardcoding specific versions of AWS clients and libraries, this change parses that file if smithy-aws-typescript-codegen is also on the classpath, so that we can use compatible versions of these packages when we generate package.json. If smithy-aws-typescript-codegen is not on the classpath we fall back to "latest" for these packages.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes:
smithy-aws-typescript-codegen bundles a properties file that has the version of
every client and library that the JS SDK vends. This essentially ties that set
of versions to the published version of the smithy-aws-typescript-codegen
package. Instead of hardcoding specific versions of AWS clients and libraries,
this change parses that file if smithy-aws-typescript-codegen is also on the
classpath, so that we can use compatible versions of these packages when we
generate package.json. If smithy-aws-typescript-codegen is not on the classpath
we fall back to "latest" for these packages.
I tested this by generating a white-label client locally with this change and the latest version of smithy-aws-typescript-codegen. My package.json file had the correct version of every package (3.22.0, in this case) and the client passed TS type checks. It does not without this change.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.