编程语言编译器云原生语言运行时【免费下载链接】wingA programming language for the cloud ☁️ A unified programming model, combining infrastructure and runtime code into one language ⚡项目地址https://gitcode.com/gh_mirrors/wi/wing点击查看免费下载本篇技术指南以 Wing 仓库中的tests/sdk_tests/bucket/events.test.w及其 hangar 编译快照tools/hangar/__snapshots__/test_corpus/sdk_tests/bucket/events.test.w_compile_tf-aws.md为切入点深入剖析cloud.Bucket的onCreate、onUpdate、onDelete、onEvent事件 API 在tf-aws目标上的落地方式从 Wing 源码中的事件声明到 SDK 如何生成 S3 事件通知、SNS Topic、Lambda 函数、IAM 权限与 DynamoDB 计数器最终形成可部署的 Terraform JSONmain.tf.json。读完本文你将掌握 Wing Bucket 事件模型的编程范式、事件类型与 S3 事件的映射关系、编译产物的资源结构以及如何像 hangar 一样用快照验证编译结果。一、事件测试用例它验证了什么快照文档标题即指向其源测试文件 events.test.w该用例位于 tests/sdk_tests/bucket 目录下与put、delete、copy、bucket_list等 20 余个用例并列专门用于验证 Bucket 对象事件的触发次数是否符合预期。测试的核心场景如下bring cloud; bring util; enum Source { anyEvent, // 由 onCreate/onUpdate/onDelete 触发 onEvent // 由 onEvent 触发 } let b new cloud.Bucket(); let idsCounter new cloud.Counter(); let logs new cloud.Bucket() as LogHistory; let logHistory inflight (key: str, operation: str, source: Source) { logs.putJson({idsCounter.inc()}, Json { key: key, operation: operation, source: {source} }); }; b.onDelete(inflight (key: str) { logHistory(key, OnDelete(), Source.anyEvent); }); b.onUpdate(inflight (key: str) { logHistory(key, OnUpdate(), Source.anyEvent); }); b.onCreate(inflight (key: str) { logHistory(key, OnCreate(), Source.anyEvent); }); b.onEvent(inflight (key: str, event: cloud.BucketEventType) { logHistory(key, {event}(), Source.onEvent); });测试语义可概括为创建一个主 Bucketb、一个cloud.Counter用于生成唯一日志编号和一个名为LogHistory的日志 Bucket通过b.onDelete / b.onUpdate / b.onCreate为单类事件注册 inflight 处理器对应Source.anyEvent再通过b.onEvent注册一个覆盖所有事件类型的处理器对应Source.onEvent每个事件处理器将(key, operation, source)三元组以 JSON 形式写入日志 Bucketkey 使用idsCounter.inc()保证唯一性。随后在std.Test中执行一系列写操作并校验事件计数new std.Test(inflight () { b.put(a, 1); b.put(b, 1); b.put(c, 1); b.put(b, 100); // 覆盖 b → 触发一次 Update b.delete(c); // 删除 c → 触发一次 Delete // https://github.com/winglang/wing/issues/2724 if target ! tf-aws { checkHitCount(key: a, type: OnCreate(), source: Source.anyEvent, count: 1); // ... 对 b、c 的 OnCreate / OnUpdate / OnDelete 计数断言 } }, timeout: 8m) as hitCount is incremented according to the bucket event;期望的计数结果a触发 1 次 Createb触发 1 次 Create 与 1 次 Update因被覆盖写入c触发 1 次 Create 与 1 次 Delete。注意代码注释中的 issue 引用由于tf-aws上 S3 事件通知存在一定的最终一致性与事件合并特性测试在target ! tf-aws时才执行严格计数断言这是仓库源码中明确记录的已知边界对应 events.test.w。二、事件 API 与事件类型SDK 层的声明事件模型定义在 SDK 的 cloud/bucket.ts 中核心是BucketEventType枚举export enum BucketEventType { CREATE OnCreate, DELETE OnDelete, UPDATE OnUpdate, }四个事件 API 均接受一个IBucketEventHandler即携带handle(key: string, type: BucketEventType)签名的 inflight 处理器当前版本中传入的 options 对象会被忽略并打印警告bucket.onCreate does not support options yetAPI触发条件关联的 Bucket 写操作源码createBucketEvent中的连接声明onCreate(fn)对象被上传put、putJsononUpdate(fn)对象被更新put、putJsononDelete(fn)对象被删除delete、tryDeleteonEvent(fn)创建 / 更新 / 删除均触发同时订阅 CREATE、UPDATE、DELETE 三个 Topic从 cloud/bucket.ts 的createBucketEvent私有方法可以看到事件机制的内部骨架每个BucketEventType对应一个内部cloud.Topic通过_topicsMap 惰性创建并缓存见getTopic事件处理器通过topic.onMessage(...)订阅同时通过构造器连接connection将put/putJson/delete/tryDelete等写方法与对应 Topic 的publish操作关联起来。这正是 Wing 应用树application tree中事件订阅即连接的体现。onEvent则是一次性订阅全部三类事件处理器会额外收到cloud.BucketEventType参数从而在回调中区分具体事件类型——这也是测试中用{event}()拼接出OnCreate()/OnUpdate()/OnDelete()日志文本的原因。三、tf-aws 平台的实现S3 事件通知 → SNS → Lambda在tf-aws目标上抽象的事件订阅被编译为一条完整的 AWS 资源链实现集中在 target-tf-aws/bucket.ts 与 target-tf-aws/topic.ts。3.1 事件类型到 S3 事件的映射target-tf-aws/bucket.ts 定义了关键映射表const EVENTS { [cloud.BucketEventType.DELETE]: [s3:ObjectRemoved:*], [cloud.BucketEventType.CREATE]: [s3:ObjectCreated:Put], [cloud.BucketEventType.UPDATE]: [s3:ObjectCreated:Post], };即onCreate→s3:ObjectCreated:Put普通 PUT 上传onUpdate→s3:ObjectCreated:Post对已存在对象的覆盖写onDelete→s3:ObjectRemoved:*所有删除类型。3.2 资源生成流程在 tf-aws 的Bucket.createTopic中每次注册事件都会创建一个 SNS Topicaws_sns_topic命名形如OnCreate-c8b721b0通过addPermissionToPublish授权s3.amazonaws.com服务主体对该 Topic 执行sns:Publish生成aws_sns_topic_policy并使用aws:SourceArn条件限定只能来自本 Bucket将(id: on-oncreate-notification, events: [...], topicArn)记入notificationTopics数组在_preSynthesize阶段统一生成一个aws_s3_bucket_notification资源把 Bucket 的三个事件绑定到对应 SNS Topic并dependsOn三个 Topic 策略以保证权限先于通知创建。而 target-tf-aws/topic.ts 的onMessage则为每个订阅创建一个 Lambda 函数aws_lambda_function并通过aws_sns_topic_subscriptionprotocol 为lambda将 SNS Topic 与函数关联同时授予 SNS 服务调用该函数的aws_lambda_permission。最终形成的事件链路S3 Bucket 写操作 → aws_s3_bucket_notification按事件类型分发 → SNS TopicOnCreate / OnUpdate / OnDelete → SNS Topic 策略s3.amazonaws.com 可 Publish限定 SourceArn → Lambda 函数事件处理器 → CloudWatch Log Group日志3.3 SNS 消息解析SNS 投递给 Lambda 的原始消息由 shared-aws/bucket.ts 的BucketEventHandler.toTopicOnMessageHandler解析它会先忽略 AWS 在真实事件前发送的s3:TestEvent测试消息再从message.Records[0].s3.object.key中提取对象 key连同事件类型一起回调用户处理器。这解释了为何 SNS 通知事件不会污染用户的计数验证。四、快照main.tf.json逐资源解读快照文档events.test.w_compile_tf-aws.md的核心内容就是 hangar 对上述用例执行wing compile -t tf-aws后生成的完整 main.tf.json。下面按资源类型解读其含义资源名即快照中的uniqueId。4.1 存储资源三个 S3 BucketuniqueId用途关键属性Bucket主事件源 Bucketbucket_prefix: bucket-c88fdc5f-、force_destroy: falseLogHistory日志存储 Bucketbucket_prefix: loghistory-c817bcb3-、force_destroy: falseCodeLambda 代码包托管 Bucketbucket_prefix: code-c84a50b1-无force_destroy由框架内部管理aws_s3_bucket: { Bucket: { //: { metadata: { path: root/Default/Default/Bucket/Default, uniqueId: Bucket } }, bucket_prefix: bucket-c88fdc5f-, force_destroy: false } }bucket_prefix由 target-tf-aws/bucket.ts 的BUCKET_PREFIX_OPTS规则生成全小写、禁止点号、最大 37 字符并以-结尾Terraform 自动补充随机后缀。此外createEncryptedBucket会校验前缀不能以xn--开头、必须以字母或数字开头。4.2 计数器DynamoDB 表cloud.Counter在 tf-aws 上落地为一张 DynamoDB 表aws_dynamodb_table: { Counter: { //: { metadata: { path: root/Default/Default/Counter/Default, uniqueId: Counter } }, attribute: [{ name: id, type: S }], billing_mode: PAY_PER_REQUEST, hash_key: id, name: wing-counter-Counter-c824ef62 } }采用PAY_PER_REQUEST按量计费模式哈希键为id字符串。事件处理器中的idsCounter.inc()在快照中体现为 Lambda IAM 策略里的dynamodb:UpdateItem权限。4.3 六个事件处理函数Lambda测试注册了 4 个处理器但 onCreate / onUpdate / onDelete 的anyEvent处理器与 onEvent 的处理器并非同一函数因此编译出 6 个 Lambda每组OnCreate/OnUpdate/OnDelete各两个例如aws_lambda_function: { Bucket_OnCreate-OnMessage0_4C972FB4: { //: { metadata: { path: root/Default/Default/Bucket/OnCreate-OnMessage0/Default, uniqueId: Bucket_OnCreate-OnMessage0_4C972FB4 } }, architectures: [arm64], environment: { variables: { BUCKET_NAME_76338bfb: ${aws_s3_bucket.LogHistory.bucket}, DYNAMODB_TABLE_NAME_6cb5a3a4: ${aws_dynamodb_table.Counter.name}, NODE_OPTIONS: --enable-source-maps, WING_FUNCTION_NAME: OnCreate-OnMessage0-c8740b4b, WING_TARGET: tf-aws } }, function_name: OnCreate-OnMessage0-c8740b4b, handler: index.handler, logging_config: { log_format: JSON }, memory_size: 1024, publish: true, runtime: nodejs20.x, s3_bucket: ${aws_s3_bucket.Code.bucket}, s3_key: ${aws_s3_object.Bucket_OnCreate-OnMessage0_S3Object_3AC22680.key}, timeout: 60, vpc_config: { security_group_ids: [], subnet_ids: [] } } }关键参数解读runtimenodejs20.x、架构arm64、内存 1024 MB、超时 60 秒这是当前仓库版本 Wing 为事件处理函数生成的默认运行时配置publish: true每次部署发布函数新版本配合 SNS 订阅的 Lambda 别名策略handler: index.handler指向 Wing 编译器生成的 JS bundle 入口代码包每个函数对应一个aws_s3_objectBucket_OnCreate-OnMessage0_S3Object_3AC22680等上传到CodeBuckets3_key以ASSET_KEY占位表示由 Wing CLI 在构建阶段注入真实资产位置环境变量BUCKET_NAME_76338bfb指向LogHistorylift 机制注入的 Bucket 名称命名规则见 shared-aws/bucket.ts 的BUCKET_NAME_${addr.slice(-8)}DYNAMODB_TABLE_NAME_6cb5a3a4指向 CounterWING_TARGETtf-aws标记目标平台NODE_OPTIONS--enable-source-maps启用源码映射便于调试日志每个函数配套一个aws_cloudwatch_log_group命名/aws/lambda/function_name如/aws/lambda/OnCreate-OnMessage0-c8740b4bretention_in_days: 30log_format: JSON。4.4 S3 事件通知aws_s3_bucket_notification这是整个事件链路的枢纽资源将 Bucket 的 S3 事件按类型路由到三个 SNS Topicaws_s3_bucket_notification: { Bucket_S3BucketNotification_D5E2F72C: { //: { metadata: { path: root/Default/Default/Bucket/S3BucketNotification, uniqueId: Bucket_S3BucketNotification_D5E2F72C } }, bucket: ${aws_s3_bucket.Bucket.id}, depends_on: [ aws_sns_topic_policy.Bucket_OnDelete_PublishPermission-..._89434C6B, aws_sns_topic_policy.Bucket_OnUpdate_PublishPermission-..._9BF3340C, aws_sns_topic_policy.Bucket_OnCreate_PublishPermission-..._E9DA9F8C ], topic: [ { events: [s3:ObjectRemoved:*], id: on-ondelete-notification, topic_arn: ${aws_sns_topic.Bucket_OnDelete_0EB7243C.arn} }, { events: [s3:ObjectCreated:Post], id: on-onupdate-notification, topic_arn: ${aws_sns_topic.Bucket_OnUpdate_E297838E.arn} }, { events: [s3:ObjectCreated:Put], id: on-oncreate-notification, topic_arn: ${aws_sns_topic.Bucket_OnCreate_9682272C.arn} } ] } }该资源的生成逻辑与 target-tf-aws/bucket.ts 的_preSynthesize完全对应topic数组来自createTopic中累积的notificationTopicsdepends_on则引用三个aws_sns_topic_policy确保 S3 的发布权限先于通知配置生效否则 Terraform 创建通知时会因权限未就绪而失败。4.5 消息路由SNS Topic、策略与订阅快照中创建了 3 个 SNS TopicOnCreate-c8b721b0、OnDelete-c8951577、OnUpdate-c81749ea每个 Topic 配套aws_sns_topic_policy授权s3.amazonaws.com发布并带有aws:SourceArn条件精确限定源 Bucket防止跨账户/跨桶误发policy: {\Statement\:[{\Effect\:\Allow\,\Principal\:{\Service\:\s3.amazonaws.com\},\Action\:\sns:Publish\,\Resource\:\${aws_sns_topic.Bucket_OnCreate_9682272C.arn}\,\Condition\:{\ArnEquals\:{\aws:SourceArn\:\${aws_s3_bucket.Bucket.arn}\}}}]}aws_sns_topic_subscription每个事件类型两个订阅对应两个处理器函数protocol: lambda、endpoint指向对应 Lambda 的 ARNaws_lambda_permission允许sns.amazonaws.com主体调用对应 Lambdaaction: lambda:InvokeFunctionsource_arn限定为 SNS Topic。4.6 最小权限 IAM每个事件函数都有一组 IAM 资源快照中Bucket_OnCreate-OnMessage0_IamRole_*、IamRolePolicy_*、IamRolePolicyAttachment_*三件套aws_iam_role信任策略仅允许lambda.amazonaws.com执行sts:AssumeRoleaws_iam_role_policy内联策略精确授予两个最小权限集——dynamodb:UpdateItem对应 Counter 的inc()与s3:PutObject*/s3:Abort*对应向LogHistory写入日志Resource 分别限定到 Counter 表与LogHistoryBucket含前缀/*aws_iam_role_policy_attachment附加 AWS 托管策略AWSLambdaBasicExecutionRole提供 CloudWatch 日志写入能力。由此可见事件处理函数只获得了执行其业务逻辑所需的最小权限这与 Wing SDK 的calculateBucketPermissions见 shared-aws/bucket.ts 的onLift权限计算一致用户 inflight 代码 lift 了哪些 Bucket/Counter 操作编译产物就生成对应的 IAM 策略。五、测试验证机制waitUntil 轮询计数checkHitCount采用了轮询直到断言成立的验证模式其底层是util.waitUntillet checkHitCount inflight (opts: CheckHitCountOptions): void { util.waitUntil(inflight () { let var count 0; for u in logs.list() { let data logs.getJson(u); if (data.get(key) opts.key data.get(operation) opts.type data.get(source) {opts.source}) { count count 1; } } return count opts.count; }, timeout: 2m, interval: 10s); };其语义每 10 秒遍历一次LogHistory统计与(key, operation, source)匹配的日志条数直到达到预期计数或 2 分钟超时。对应 SDK 中 util/util.ts 的waitUntil实现默认超时 1 分钟、轮询间隔 0.1 秒此处显式覆盖为 2m / 10s若谓词在超时前返回true则成功返回否则抛出Timeout elapsed错误。整体测试用例std.Test的超时设为 8 分钟timeout: 8m。这种轮询设计是刻意为之S3 事件通知属于异步分发事件到达 SNS/Lambda 存在延迟因此不能同步断言必须等待事件最终送达。也正因如此测试对tf-aws目标做了跳过处理issue 2724仅在其他目标上执行严格计数。六、快照与 hangar如何复现与验证编译产物本文剖析的快照文件是 Wing 工具链测试框架 hangar位于 tools/hangar的产物。hangar 的测试目录布局如下源测试用例tests/sdk_tests/bucket/events.test.w以及tests/sdk_tests下 api、queue、math、std 等 20 余个资源模块的用例编译快照tools/hangar/snapshots目录按test_corpus/sdk_tests/bucket/组织结构保存每个用例在tf-aws以及 sim 等其他目标下的编译结果命名规则为用例名_compile_目标.md快照生成逻辑tools/hangar/src 中的generate_tests.ts、paths.ts定义snapshotDir路径与utils.ts。hangar 的工作方式可概括为将每个.test.w用例以指定目标平台执行wing compile把生成的main.tf.json序列化为 Markdown 快照与既有快照比对snapshot 测试任何源码或编译器改动导致编译产物变化都会通过快照 diff 暴露出来。因此像events.test.w_compile_tf-aws.md这样的快照不仅是 Terraform 配置的真实记录更是 SDK 生成逻辑的回归测试基线——当你修改 cloud/bucket.ts 或 target-tf-aws/bucket.ts 的事件实现时本快照就是校验编译产物是否符合预期的第一道防线。要在本地复现该编译产物可在仓库根目录执行wing compile -t tf-aws配合 package.json 中配置的构建脚本与 tools/hangar 的 vitest 配置运行快照测试。需要注意的是快照中的ASSET_KEY/ASSET_SOURCE为资产占位符真实部署时由 Wing CLI 构建阶段填充。七、小结通过events.test.w及其 tf-aws 快照可以完整看到 Wing 单一语言模型在 Bucket 事件场景下的价值开发者只需用onCreate/onUpdate/onDelete/onEvent声明式订阅SDK 便自动生成 S3 事件通知、SNS Topic、Lambda 函数、CloudWatch 日志、DynamoDB 计数、最小权限 IAM 以及 SNS 发布/调用权限共 12 类 Terraform 资源快照中可见aws_cloudwatch_log_group、aws_dynamodb_table、aws_iam_role、aws_iam_role_policy、aws_iam_role_policy_attachment、aws_lambda_function、aws_lambda_permission、aws_s3_bucket、aws_s3_bucket_cors_configuration、aws_s3_bucket_notification、aws_s3_object、aws_sns_topic、aws_sns_topic_policy、aws_sns_topic_subscription且每个资源都遵循最小权限原则。这种抽象 API 平台编译产物 快照回归的三层结构正是 Wing 云编程模型在 tests/sdk_tests 与 tools/hangar/snapshots中的典型呈现方式。赞分享编程语言编译器云原生语言运行时【免费下载链接】wingA programming language for the cloud ☁️ A unified programming model, combining infrastructure and runtime code into one language ⚡项目地址https://gitcode.com/gh_mirrors/wi/wing点击查看免费下载相关推荐Wing 云 API 的 tf-aws 编译产物剖析从 post.test.w 快照看 API Gateway Lambda 落地Wing 云 API 的 tf aws 编译产物剖析从 post.test.w 快照看 API Gateway Lambda 落地 导读 本文以 Wing编程语言编译器云原生语言运行时Wing 云 API 路径变量实战从 root_path_vars 测试到 tf-aws 编译产物深度解析Wing 云 API 路径变量实战从 root_path_vars 测试到 tf aws 编译产物深度解析 导读 本篇围绕 Wing 语言 SDK 中 clo编程语言编译器云原生语言运行时Wing 云 API 处理器环境变量注入从 env: 选项到 tf-aws 编译产物的完整链路解析Wing 云 API 处理器环境变量注入从 env: 选项到 tf aws 编译产物的完整链路解析 本文以 Wing 语言仓库中 env.test.w 的 t编程语言编译器云原生语言运行时上一篇用 PM Skills 的 marketing-ideas 技能批量产出高性价比营销创意下一篇FreeLLMAPI 实战指南把 34 家免费 LLM 供应商聚合到一个 OpenAI 兼容网关创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考