Soto 的代码生成器，使用 AWS 提供的 Smithy 模型为 AWS 生成 Swift 客户端代码。

Soto 仓库非常庞大，通常大多数项目只需要它支持的众多服务中的一部分。为了避免下载整个项目，我们构建了一个 Swift Package Manager 构建插件，它将 Smithy 模型文件到 Swift 的转换添加到您的构建过程中。

.package(url: "https://github.com/soto-project/soto-codegenerator", from: "0.6.0"),
.package(url: "https://github.com/soto-project/soto-core.git", from: "6.4.0")

.target(
    name: "MySotoServices",
    dependencies: [.product(name: "SotoCore", package: "soto-core")],
    plugins: [.plugin(name: "SotoCodeGeneratorPlugin", package: "soto-codegenerator")]
)

构建插件将首先在您的目标根目录中搜索 endpoints.json，然后在您的项目根目录中搜索。模型文件应添加到您的目标中。除非您正在使用新的区域端点或服务的新功能，否则您无需再次更新这些文件。

如果您的目标仅包含 AWS Smithy 模型文件，您需要在文件夹中添加一个虚拟的空 Swift 文件。否则，Swift Package Manager 将警告您目标没有源文件，并且不会构建目标。

swift build

构建插件会将生成的 Swift 代码放在 .build/plugins/outputs/<package name>/<target name>/SotoCodeGeneratorPlugin/GeneratedSources 中，并将其包含在该目标的 Swift 文件列表中。

如果您依赖于 Soto 的扩展代码（例如 S3 多部分上传、STS/Cognito 凭证提供程序或 DynamoDB Codable 支持），则此过程可能不适用于您，因为扩展代码未生成且不可用。

您可以将配置文件 soto.config.json 添加到您的项目中，以控制 Swift 代码生成。

许多服务都有大量您可能永远不会使用的操作。如果您在低内存环境（例如 AWS Lambda 或 iOS 应用程序）中工作，并且只使用 s3.getObject，为什么要在您的代码库中包含其他 94 个 S3 操作的代码呢？配置文件可用于过滤您要为其生成代码的操作。以下 soto.config.json 将仅输出 getObject 的代码。

{
    "services": { 
        "s3": {
            "operations": ["getObject"]
        }
    },
}

您可以在 services 字段下列出多个服务。在此示例中，s3 是服务名称，应与从中生成服务的 Smithy 模型文件名相同，操作列表需要与生成的函数名称相同，即驼峰式命名，首字母小写。

如果您不想要像 operations 字段那样静态的内容，还有 access 字段，这是一个全局字段，用于控制生成代码的访问控制。可以将其设置为 internal 或 public。

{
    "access": "internal"
}

将其设置为 internal 会将您的代码的访问控制设置为 internal，并且您只能在同一目标中使用生成的代码。然后，链接器应该能够删除任何未使用的生成代码。如果您只使用 s3.getObject，您将只链接 s3.getObject 的代码。

Soto 代码生成器

构建插件

设置

缺失代码

配置文件