[Feature]: Migrating nested type definitions from v2 to v3

[eddwon]

Self-service

• I'd be willing to implement this feature

Test Comand

npx aws-sdk-js-codemod --dry --print -t v2-to-v3 example.ts

Input code

import { S3 } from "aws-sdk";
const testTags: S3.Tag[] = [{ Key: "abc", Value: "value" }];

Current Output

Results:
0 errors
1 unmodified
0 skipped
0 ok

Expected Output

import { Tag } from "@aws-sdk/client-s3";
const testTags: Tag[] = [{ Key: "abc", Value: "value" }];

Additional context

Would it be possible to migrate the import of Typescript type definitions from v2 to v3?
My project has a global store that uses the AWS SDK types to store objects and tags. During migration, it'll be great to also have those types updated to their v3 references.

[trivikr]

Would it be possible to migrate the import of Typescript type definitions from v2 to v3?

Yes. The transformation for top-level Input/Output types was added in #209

Most of the type definitions are same between v2 and v3.
However, v2 contains some additional types which are not present in v3, and supporting them won't be straightforward.

Some of them are not required like:

• Type which is an alias for native type, like ListTablesInputLimit is for number https://github.com/aws/aws-sdk-js/blob/eef9d5895e07327ca3fb655fe79e90a993279aff/clients/dynamodb.d.ts#L2323
• Type for arrays, like AttributeDefinitions https://github.com/aws/aws-sdk-js/blob/eef9d5895e07327ca3fb655fe79e90a993279aff/clients/dynamodb.d.ts#L489

We'll have to write a script, similar to generateNewClientTests, which reads models from v2 and creates a mapping of types between v2 and v3.

[trivikr]

I posted a draft PR providing an example of complex case of type differences between v2 and v3.

#274

[trivikr]

Support for basic type definitions was added in #276, and released in https://github.com/awslabs/aws-sdk-js-codemod/releases/tag/v0.8.0

$ npx aws-sdk-js-codemod --version
aws-sdk-js-codemod: 0.8.1

jscodeshift: 0.14.0
 - babel: 7.20.5
 - babylon: 7.20.5
 - flow: 0.196.1
 - recast: 0.21.5
 
$ cat example.ts
import { S3 } from "aws-sdk";
const testTags: S3.Tag[] = [{ Key: "abc", Value: "value" }];

$ npx aws-sdk-js-codemod -t v2-to-v3 example.ts

$ cat example.ts
import AWS_S3, { S3 } from "@aws-sdk/client-s3";
const testTags: AWS_S3.Tag[] = [{ Key: "abc", Value: "value" }];

[trivikr]

I posted a draft PR providing an example of complex case of type differences between v2 and v3.
#274

For supporting these transformation, the solution we internally agreed on is to create a data structure which stores types in v2 which are either native types, or a superset of native types as follows:

"DynamoDB": {
...
  "AttributeNameList": "Array<string>",
...
  "FilterConditionMap": "Record<string, Condition>",
...
  "PositiveIntegerObject": "number",
...
  "Select": "string",
...
  "TableName": "string",
...
}

The codemod will check if the key exists in v2 application code, and add equivalent native type in generated v3 application code, likely in https://github.com/awslabs/aws-sdk-js-codemod/blob/d16d0daf27a06a6c2686e179457d0fdc89f23347/src/transforms/v2-to-v3/ts-type/getV3ClientTypeName.ts#L16C3-L18

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.