我们如何为 JavaScript 客户端减半模块化 AWS SDK 的发布规模

最新推荐文章于 2023-10-18 19:44:34 发布

owenzhang24

最新推荐文章于 2023-10-18 19:44:34 发布

阅读量242

点赞数

文章标签： python java 大数据人工智能机器学习

本文链接：https://blog.csdn.net/owenzhang24/article/details/122234015

版权

原文地址：How we halved the publish size of modular AWS SDK for JavaScript clients
原文作者：Trivikram Kamat
译文出自：掘金翻译计划

原文链接：https://aws.amazon.com/cn/blogs/developer/how-we-halved-the-publish-size-of-modular-aws-sdk-for-javascript-clients/

2020 年 12 月 15 日，我们宣布为 JavaScript 提供 AWS SDK，版本 3 (v3). 在 v3中，模块化包将应用程序的捆绑大小比 AWS SDK 中的 JavaScript(版本 2)减少了75%。但是，v3 对于每个模块化包具有较大的发布/安装大小。在这篇文章中，我们报道了如何将 v3 模块化封装的发布大小减少50%。

我们为什么要这么做？

JavaScript 社区经常拿 node_modules大尺寸开玩笑 😉

因此，我们一直在寻找机会来减少我们的包装尺寸。在与 AWS Lambda 团队合作提供 v3 时，我们专注于减少模块化封装的安装尺寸。社会上有改进建议我们还有积压项目需要处理。 (https://github.com/aws/aws-sdk-js-v3/issues/1594) (https://github.com/aws/aws-sdk-js-v3/issues/1306)

我们完成了什么？

我们很高兴地报告，我们减少了v3模块化包的发布大小+50%在v3.36.1相比，在v3.33.0！作为效果，每个客户端的安装尺寸也减少了+40%。

您可以检查在包装恐惧症上安装模块化包的成本。以下屏幕截图显示发布/安装版本的大小减少导致 v3.36.1：@aws-sdk/*@aws-sdk/client-sts

在顶级客户端中安装尺寸减少

客户群的整体未包装发布规模减少幅度在40%到60%之间。例如，下图显示了前 5 个下载客户端的未包装发布大小缩减：

``` @aws-sdk/client-sso : [███████████████░░░░░░░░░░░░░░░░░░░░░░] 41.39% @aws-sdk/client-sts : [█████████████████████░░░░░░░░░░░░░░░░] 58.09% @aws-sdk/client-s3 : [██████████████████████░░░░░░░░░░░░░░░] 59.09% @aws-sdk/client-cognito-identity: [██████████████████░░░░░░░░░░░░░░░░░░░] 49.94% @aws-sdk/client-firehose : [███████████████████░░░░░░░░░░░░░░░░░░] 51.11%

```

Bash

对于最大的 5 个客户端，未包装的发布规模减少了>50%：

``` @aws-sdk/client-ec2 : [████████████████████░░░░░░░░░░░░░░░░░] 53.85% @aws-sdk/client-sagemaker : [████████████████████░░░░░░░░░░░░░░░░░] 53.76% @aws-sdk/client-iot : [███████████████████░░░░░░░░░░░░░░░░░░] 51.63% @aws-sdk/client-chime : [███████████████████░░░░░░░░░░░░░░░░░░] 50.47% @aws-sdk/client-rds : [████████████████████░░░░░░░░░░░░░░░░░] 54.22%

```

Bash

不同版本之间的大小比较 node_modules

如果您将客户端安装到新的工作空间中，并检查node_modules内的封装大小，您将看到 v3.36.1 中的磁盘使用量减少。

例如，安装创建大小为8.9 MB的node_modules。客户端-sts 的大小为1.4 MB，包含115个文件，代码行为10054行。 @aws-sdk/client-sts@3.33.0

``` $ npm install @aws-sdk/client-sts@3.33.0 --save-exact ...

$ du -sh --apparent-size nodemodules
8.9M nodemodules

$ du -sh --apparent-size nodemodules/@aws-sdk/client-sts 1.4M nodemodules/@aws-sdk/client-sts

$ npx cloc node_modules/@aws-sdk/client-sts 163 text files. 160 unique files.

48 files ignored.

Language files blank comment code

JavaScript 45 0 1948 4674 TypeScript 64 321 7506 4295 Markdown 2 1679 0 825

JSON 4 0 0 260

SUM: 115 2000 9454 10054

```

Bash

该版本创建一个大小为5.7MB的node_modules。客户端代码大小为603 KB，包含85个文件，代码行为 6585行。 @aws-sdk/client-sts@3.36.1 ``` $ npm install @aws-sdk/client-sts@3.36.1 --save-exact ...

$ du -sh --apparent-size nodemodules 5.7M nodemodules

$ du -sh --apparent-size nodemodules/@aws-sdk/client-sts 603K nodemodules/@aws-sdk/client-sts

$ npx cloc node_modules/@aws-sdk/client-sts 88 text files. 86 unique files.

3 files ignored.

Language files blank comment code

JavaScript 40 0 0 4383 TypeScript 42 185 2481 1236 Markdown 2 1711 0 840

JSON 1 0 0 126

SUM: 85 1896 2481 6585

```

Bash

我们怎么做到的？

我们创建了客户端 s3 源代码的副本在 trivikr/temp-client-s3. 这使我们能够快速移动、快速实现和测试想法，并量化发布/安装尺寸的缩减。我们浏览了每个文件被发布到npm的客户-s3包，并问自己它扮演什么角色。我们集思广益，并将它们记录在 GitHub 问题中。然后，我们按投资回报率的下降顺序实施这些想法。

我们发布了每个版本 @trivikr-test/client-s3 并进行了具体更改，并记录了 npm 发布的指标。我们在 trivikr/debug-temp-client-s3, 测试了调试体验，并在 node.js、浏览器和反应原生环境中验证了 aws-samples/aws-sdk-js-tests#103的功能。

我们通过多个 JavaScript 兴趣渠道(包括 Github、Twitter，甚至内部 Slack 房间)分享了有关这些改进的详细信息，以便尽早从社区获得反馈。

我们从开发人员那里得到了总体的积极反馈：

主要学习是：

为开发人员提供可玩的实验性器件。
提出具体问题以获得答复。
在他们的反馈上进行重温！

我们改变了什么？

一旦我们量化了 npm 发布更改数字，我们就入围了在 v3 中实现的四个最佳改进：

我们从*.js的文件中删除了注释。
我们从*.d.ts文件中删除了注释。
我们删除了TypeScript源代码。
我们删除了源地图文件。

v3 SDK 以 TypeScript 编程语言编写。 TypeScript 通过添加类型来扩展 JavaScript，并在运行代码之前节省捕获错误和提供修复程序的时间。我们已经详细介绍了为什么我们在关于一流类型脚本支持的博客文章中选择了first-class TypeScript support.

我们从`*.js`的文件中删除了注释

我们将类型脚本代码转换到 JavaScript 在节点的常见目标中.js 和浏览器的 es5 目标。我们还将类型作为分布在不同的文件夹中。

为了帮助客户，服务船提供了广泛的服务和运营文档。我们在 JSDoc 评论中添加此文档。在我们的 TSConfig 设置中，我们在每个分发中都发货了多余的注释。

当您在代码中的符号上悬停时，JSDoc 评论会出现。在下面的示例中，当在导入上盘旋时，您会看到 DynamoDB 的 JSDoc。

此 JSDoc 来自文件。我们从*.d.ts的文件中删除了多余的注释，这导致未包装的发布大小减少了 ~6%

``` $ pwd /home/trivikr/workspace/aws-sdk-js-v3/clients/client-sts

Before the change

$ du -sh --apparent-size dist/cjs | cut -f1 301K

$ npx cloc dist/cjs ...

Language files blank comment code

JavaScript 22 0 974 2328 ...

After the change

$ du -sh --apparent-size dist/cjs | cut -f1 239K

$ npx cloc dist/cjs ...

Language files blank comment code

JavaScript 22 0 0 1354 ...

```

Bash

我们从`*.d.ts`文件中删除了注释

为了支持使用旧版本的类型脚本的客户，我们使用 downlevel-dts 将具有新类型脚本功能的代码转换为使用等效旧功能的代码的下级类型。此功能在下级类型中添加重复注释，从而增加发布规模。

我们从*.d.ts文件中删除了注释，这导致未包装的发布大小减少了 ~10%

``` $ pwd /home/trivikr/workspace/aws-sdk-js-v3/clients/client-sts

Before the change

$ du -sh --apparent-size dist-types | cut -f1 742K

$ npx cloc dist-types ...

Language files blank comment code

TypeScript 59 0 4962 1813 ...

After the change

$ du -sh --apparent-size dist-types | cut -f1 396K

$ npx cloc dist-types ...

Language files blank comment code

TypeScript 59 185 2481 1813 ...

```

Bash

因此，使用 4.0 以上的 TypeScript 版本的客户不会在其 IDE 中看到 JSDoc 评论，尽管下级类型将起作用。我们继续这一变化，以鼓励客户切换到类型Script 4.0+，这是在 2020年8月发布。

如果您使用类型脚本 <4.0，则 SDoc 评论将显示 SDK 版本< 3.36.0。

我们删除了TypeScript源代码

JavaScript 图书馆的作者根据各种原因决定编写图书馆的语言。例如，我们使用类型脚本 v3 的原因解释在博客文章中关于first-class TypeScript support. 其他维护者可以选择不同的语言来编写他们的图书馆：JavaScript，复稿，纯脚本，关闭脚本，咖啡脚本，理性，埃尔姆，流等。图书馆的消费者不必知道图书馆所写的语言。最后，发动机处理 JavaScript 代码。

要提供一流的类型脚本支持，库需要运送类型。如果库不是用类型脚本书写的，他们要么手动编写类型，要么使用类型脚本生成类型声明。

我们在推特上问了这样一个问题，维护者是否将源代码以 npm 包中运送。以下是其中一个答复中的一段话："航运源代码违背了模块定义的精神"。

我们将已发布软件包中的源代码以及其他开发/测试配置删除，这导致未包装的发布大小减少了 ~28% reduction

``` $ pwd /home/trivikr/workspace/aws-sdk-js-v3/clients/client-sts

Before the change

$ npm pack --dry-run ... package size: 141.7 kB
unpacked size: 1.2 MB
total files: 177 ...

After the change

$ npm pack --dry-run ... package size: 99.9 kB
unpacked size: 783.8 kB
total files: 88 ...

```

Bash

我们删除了源地图文件

Source map files允许调试器和其他工具在实际处理发射的 JavaScript 文件时显示原始 TypeScript 源代码。在类型脚本中，源映射文件以(或)文件的身份在相应的输出文件旁边发出。类型脚本还允许将源地图内容嵌入到文件中。TypeScript 还允许将文件的原始内容作为嵌入字符串包含在源地图中。.js.map.jsx.map.js.js.ts

源地图文件有助于调试应用程序代码。它们对于必须满足严格的发布/安装尺寸限制的图书馆和依赖者没有用处。更好的解决方案是发布 SDK 的调试版本。如果您有关于源图的反馈，或想解释您的调试或其他使用案例，请评论 GitHub 问题 aws/aws-sdk-js-v3/#2895.

在 TypeScript publishing guide出版指南中，没有关于发布源图的建议。在 TSConfig 中，默认情况下会关闭sourceMap, inlineSourceMap and inlineSources 的设置。

我们从 v3 中删除了源图，这导致未包装的发布大小减少了 ~20%

``` $ pwd /home/trivikr/workspace/aws-sdk-js-v3/clients/client-sts

Before the change

$ du -sh --apparent-size dist-cjs | cut -f1 246K

$ npx cloc dist-cjs ... 42 text files. 42 unique files.
21 files ignored. ...

After the change

$ du -sh --apparent-size dist-cjs | cut -f1 174K

$ npx cloc dist-cjs ... 21 text files. 21 unique files.
0 files ignored. ...

```

Bash

社区的反应是什么？

我们得到了来自推特社区的压倒性回应，这些令人兴奋的消息！

加入 Twitter上的对话让我们知道您是如何减少发布/安装/捆绑大小在你的npm包或任何其他经验，你已经与AWS SDK为JavaScript。

我们计划将来做什么？

为了确保我们防止腹胀偷偷溜回来，我们计划添加 CI 来检查发布大小。

我们还没有缩小实际源代码的大小。例如，API 呼叫的通用功能将使源代码的大小减少 ±0.5%。如果您有任何想法来减少发布规模，请将其发布到我们的实验回购中，trivikr/temp-client-s3/issues发布。

我们也没有考虑使用高级或替代的汇编选项，如谷歌关闭编译器，巴贝尔或SWC。如果您有想法/建议或例子，他们如何可以帮助，请评论 GitHub 问题 aws/aws-sdk-js-v3/#2897.

我们也在考虑航运节点.js特定的分布和类型定义分布在单独的预发行版本编号，这可能进一步减少npm安装大小从之间 60% 和 75``%. 虽然预期的改进是巨大的，但实施之前需要大量的讨论和测试。请在 GitHub 问题 aws/aws-sdk-js-v3/#2889上发布您的想法/建议/关注。

如果您有关于类型脚本源代码和源图的反馈，或想解释您的调试或其他使用案例，请评论 GitHub 问题 aws/aws-sdk-js-v3/#2895.

您如何做出贡献？

我们重视您的反馈，因此请通过在 [GitHub] (https://github.com/aws/aws-sdk-js-v3/)上打开一个问题来告诉我们您喜欢和不喜欢什么。减少安装/发布大小是双向决策。如果 GitHub 破坏了您的开发人员体验，请通知我们。

owenzhang24

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
我们如何为 JavaScript 客户端减半模块化 AWS SDK 的发布规模

原文地址：How we halved the publish size of modular AWS SDK for JavaScript clients 原文作者：Trivikram Kamat 译文出自：掘金翻译计划原文链接：https://aws.amazon.com/cn/blogs/developer/how-we-halved-the-publish-s...
复制链接

扫一扫