deps(cw): regen clients with codegen at 0.25.x (IGNORE)

[Hweinstock]

Problem

Solution

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

• This pull request modifies code in src/* but no tests were added/updated.
  • Confirm whether tests should be added or ensure the PR description explains why tests are not required.

[trivikr]

The [email protected] published <v3.696.0 of JS SDK v3 in aws/aws-sdk-js-v3#6673

Since this is a monorepo which has a single lock file across all clients, the version of client packages need to be updated to <3.696.0 in https://github.com/Hweinstock/aws-toolkit-vscode/blob/3c37c5777ac395c5f1b59da3d7599b1e554210d8/packages/core/package.json#L499-L504

Since AWS SDK for JavaScript v3 follows fixed versioning, the <3.696.0 version can be applicable to other @aws-sdk/* dependencies too.

[trivikr]

As there's another codegen client @amzn/amazon-q-developer-streaming-client, it should also be codegen with 0.25.x as it's also part of monorepo.

https://github.com/Hweinstock/aws-toolkit-vscode/blob/3c37c5777ac395c5f1b59da3d7599b1e554210d8/src.gen/%40amzn/amazon-q-developer-streaming-client/package.json#L23-L34

It currently uses old codegen version.

[Hweinstock]

I pinned the @aws-sdk/* packages to be <3.696.0 and regenerated the other client with codegen version 0.25.x. Are there any other steps I should take here? Otherwise planning to retry with 0.26.x once its available.

[trivikr]

I pinned the @aws-sdk/* packages to be <3.696.0

I see that you've use exact version 3.696.0.
https://github.com/Hweinstock/aws-toolkit-vscode/blob/b1470ed160aa114012e8cbee9dbac00969c9a8df/packages/core/package.json#L499-L510

Can you use <3.696.0 for all @aws-sdk/* dependencies?

There's no issue with using exact version as it'll be just one version above previous one.
But since all JS SDK clients follow fixed versioning, and we don't release new versions if there are no updates in specific clients or it's dependencies, we suggested <.

[trivikr]

For a detailed explanation, if you search for @aws-sdk/client-sso-oidc in package-lock.json, it contains both 3.693.0 and 3.696.0
https://github.com/Hweinstock/aws-toolkit-vscode/blob/b1470ed160aa114012e8cbee9dbac00969c9a8df/package-lock.json

• It contains 3.693.0 since generated clients depend on it https://github.com/Hweinstock/aws-toolkit-vscode/blob/b1470ed160aa114012e8cbee9dbac00969c9a8df/src.gen/%40amzn/amazon-q-developer-streaming-client/package.json#L23
• It contains 3.696.0 since core depends on it https://github.com/Hweinstock/aws-toolkit-vscode/blob/b1470ed160aa114012e8cbee9dbac00969c9a8df/packages/core/package.json#L504

If you use <3.696.0 on core package, it'll use 3.693.0.
Similarly if you pin other non-client @aws-sdk/* packages to <3.696.0, other dependency conflicts will get resolved.

[Hweinstock]

I see, thanks for the explanation that makes a lot of sense. I switched it to to be <3.696.0 and verified there is only one version (3.693.0) of @aws-sdk/client-sso-oidc in the package-lock now. Unfortunately, it doesn't seem to solve the smithy package conflicts, but this version pinning done here has eliminated all the errors I was originally seeing with type mismatches so I think we're getting closer.

[trivikr]

I'm glad that versioning issues with @aws-sdk/* are no longer there.

Do update your Contributor Guide with learnings from this PR. The AWS SDK for JavaScript team will take a backlog to write a doc on versioning from this experience - possibly in our Developer Guide. We'll get it reviewed from you internally before publishing.

[trivikr]

Tackling @smithy/* versioning is little tricky, but we use latest for those packages as they can be used outside of AWS too. Your monorepo can do the same.

I see that you're using 5 dependencies from @smithy

        "@smithy/middleware-retry": "^2.3.1",
        "@smithy/protocol-http": "^3.3.0",
        "@smithy/service-error-classification": "^2.1.5",
        "@smithy/shared-ini-file-loader": "^2.2.8",
        "@smithy/util-retry": "^2.2.0",

https://github.com/Hweinstock/aws-toolkit-vscode/blob/83a18cc84e7a4317048b4ddc12357c65ae310e3e/packages/core/package.json#L514-L518

An easy fix would be to copy the same version used by your code generated packages. i.e.

        "@smithy/middleware-retry": "^3.0.27",
        "@smithy/protocol-http": "^4.1.7",
        "@smithy/service-error-classification": "^3.0.11", // not direct client dependency, found from package-lock
        "@smithy/shared-ini-file-loader": "^3.1.12", // not direct client dependency, found from package-lock
        "@smithy/util-retry": "^3.0.10",

Since it's the latest major version, you can use ^N.0.0 if it simplifies your tooling

        "@smithy/middleware-retry": "^3.0.0",
        "@smithy/protocol-http": "^4.0.0",
        "@smithy/service-error-classification": "^3.0.0",
        "@smithy/shared-ini-file-loader": "^3.0.0",
        "@smithy/util-retry": "^3.0.0",

[Hweinstock]

Thanks for the help! I was able to get it building by fixing the smithy versions. The tests are now failing since the code that relied on the older versions of @smithy/* packages does not work on the newer versions, and I implemented some workarounds just so that it builds for now.

Assuming we can update that code to work with the newer smithy versions, I want to make sure I understand how to avoid this in the future. Here is my understanding of what we had to do to fix this:

• generate all clients from the same version of codegen. (in this case 0.25.x).
• fix @aws-sdk/* package versions in the root to be no-newer than the version fixed by codegen. (in this case <3.696.0)
• fix @smithy/* package versions to the same major versions used by the generated clients (including indirect dependencies from the package-lock.json) on a per package basis. I emphasize the last point because its not intuitive that the generated client uses "@smithy/middleware-retry": "^3.0.27" and "@smithy/protocol-http": "^4.1.7" despite coming from the same codegen version, so one needs to check that each package lines up.

Feel free to let me know if I missed any important steps above. Also a few follow up questions:

• Is there any recommended way to go about enforcing these constraints? Any solutions from other teams that have been effective?
• Is this something we will always have to deal with when consuming generated typescript clients from smithy? Are there any plans to improve this experience?
• Since we don't own the packages that generate these clients, is there anything we can do when their codegen versions inevitably diverge? Is our only option to block merges/changes to them in this repo until they are in sync?
• How do we determine the version to fix based on the codegen version? Does it require manually looking at the generated package.json and taking the newest version of an @aws-sdk/* package?
• What happens if we need to update a package we consume in the toolkit but there isn't a version of codegen available that lets us pin to a newer version?

Thank you again for your help on this issue! This has been a huge headache for us, and its refreshing to see a path out of it.