Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Migrate away from class-transfomer

未关闭
  • 哪里不对？
#100 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
技术栈
javascript, nodejs, typescript
领域
developer-experience, tooling

调研方向

首先审查 issue 68 和提议的 handlers.ts 示例，然后检查 issue 所述需要更改的 SDK 和生成代码。在评估 camelcase-keys、AJV 和 json-schema-to-typescript 之前，跟踪当前的 class-transformer 集成并确定受影响的入口点。完成的标准是：plugin 不再依赖 class-transformer，支持提议的 JavaScript 和 TypeScript 工作流，并包含所需的 SDK 和生成代码更改。

由索引模型根据 Issue 内容生成。

描述

This is a rethought version of my previous ticket https://github.com/aws-cloudformation/cloudformation-cli-typescript-plugin/issues/68

To resummarize the issues with class-transformer:

  • The serialization breaks down in the face of unsupported CloudFormation JSON Schema Features, and increases complexity since JSON Schema features must be manually mapped to the Class Transformer equivalent.
  • It ties the implementation to TypeScript's decorators which are soon to be completely deprecated and redesigned entirely, and results in a data model that might be foreign to a lot of JavaScript developers today (outside angular and nestjs)
  • Because of the above, it prevents JavaScript from working (though I'd personally always encourage TS over JS) (https://github.com/aws-cloudformation/cloudformation-cli-typescript-plugin/issues/8)
  • The project isn't also super alive right now: https://github.com/typestack/class-transformer/issues/1272 Possibly no longer as valid, it looks like the projects might be getting new maintainers.

The updated proposal proposes swapping class-transformer with three components:

  • The package camelcase-keys to handle the CloudFormation-to-JS object key camelcasing.
  • The package AJV to handle validating the incoming event properties, provide friendly(er) error messages, as well as automatic type conversion
  • The package json-schema-to-typescript to handle consuming the resource definition and outputting type information for a richer experience.

While a very large change, it would uncouple this plugin from TypeScript and an unmaintained library while hopefully simplifying the Dev UX of developing a resource in typescript.

For example, a simple handler like the template default would become (example greatly appreviated):

// handlers.ts
import { Resource, TypeConfiguration } from "./.generated/models";
import { createResource, ProgressEvent, exceptions } from '@amazon-web-services-cloudformation/cloudformation-cli-typescript-lib';

const { entrypoint, testEntrypoint } = createResource<Resource, TypeConfiguration>({
    typeName: Resource.TypeName,
	schema: Resource.Schema,
    // Type information for all the below is automatically infered
	async create({ session, properties, request, logger, typeConfiguration }) {
        // Example:
        try {
			const { apiKey } = typeConfiguration;
            const response = await fetch(`https://api.someservice.com`, {
              method: 'POST',
              headers: { 'x-api-key': apiKey },
              body: { ...properties },
			});
            const { id } = await response.json();
            properties.id = id;
            // else handle error
        } catch(err) {
            logger.log(err);
            // exceptions module lets CloudFormation know the type of failure that occurred
            throw new exceptions.InternalFailure(err.message);
            // this can also be done by returning a failed progress event
            // return ProgressEvent.failed(HandlerErrorCode.InternalFailure, err.message);
        }
        return properties;
    },
    /* more handlers.... */
    async list({ properties, typeConfiguration }) {
	   /* ...some list code... */
       // Just return a plain array of models, validate via typescript & ajv
       return [/* list of plain old javascript models */];
    },
});

export { entrypoint, testEntrypoint };

This also externalizes a lot of concerns unnecessary to the user code, infers a lot more of type information automatically, and makes developing resource types much less mentally onerous allowing developers to focus on business logic.

It would require more work with the SDK and generated code however.

主要语言
TypeScript
星标
46
派生
18
30 天内没有已合并 PR

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

aws-cloudformation/cloudformation-cli-typescript-plugin 的其他 Issue

查看 aws-cloudformation/cloudformation-cli-typescript-plugin 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。