最近发现项目的node_modules打包越打越大，不看不知道，一看吓一跳。
腾讯云的 sdk 85M ，为了对比，还特地看了下@aws-sdk。
cd node_modules && du -sh * | sort -h
13M @aws-sdk
.
.
.
12M prisma
13M @types
17M @sentry
23M typescript
29M @opentelemetry
38M @prisma
85M tencentcloud-sdk-nodejs

进一步去里面看了下cd node_modules/tencentcloud-sdk-nodejs && du -sh * | sort -h
537K examples
3.9M test
4.9M SERVICE_CHANGELOG.md
5.1M CHANGELOG.md
28M src
34M tencentcloud

这 src 和 tencentcloud 是不是重复了？
还有一个 CHANGELOG 和 SERVICE_CHANGELOG 都快 10M 了。

我这是后端项目，生产环境是在 docker 里面跑 node src/index.js

稍微批评鼓励了一下他们

github.com/TencentCloud/tencentcloud-sdk-nodejs/issues/160

大了说明高级啊。 反正是 sdk 嘛。问题不大。

估计是机器生成的代码。不过 disk 反正不贵问题不大，主要关注 build 后多大就行了。

build 后是啥意思哦? 我这个 node_modules 就直接是生产环境的依赖, 生产环境里就是这么大哇?

见怪不怪。在服务器跑的无所谓。

都用 node 了还在乎这个...

跑在服务端其实无所谓，在意的话自己 fork 改一下

生产服务器上是直接 npm run dev 运行的？

build 后才是发布用的（通常是 npm run build ），一般打包发布后都不依赖 node_modules 了；你现在项目应该是开发阶段（通常是 npm run dev ），所以才需要 node_modules ，你说的“生产环境” 是指你现在开发的机器是线上的吧? 跟项目的生产发布不是一回事

大概率只是 tx 这边发布到 npm 的时候没过滤掉多余的文件而已，实际你代码使用到的只是构建产物

我咋记得腾讯云的包都是按业务分的？可能这个是总包？

我这是后端项目，生产环境是 npx tsc && node src/index.js 的。
npx tsc 过程并不会删除不需要的文件吧？

我这是后端项目，生产环境是 npx tsc && node src/index.js 运行的。

在 Node 项目里 build 主要就是 transpile/minify/treeshake 代码，你用 typescript 的话就是 tsc 那步，之后 build 出来的 index.js 体积就小了。不过后端项目没下载那一步应该没啥影响，除非你是上 serverless ，那不同的 runtime 可能会有体积限制。

影响倒是没有大影响，只不过进去一看 dependencies 的大小，吓一跳，tencentcloud 居然接近 100m 。

对比 go 包更吓人，aws 的 go 语言 sdk ，来到了 2G 多

只有 tencentcloud 这个文件夹是实际在跑的代码。。。

虽然喷人不对，但是支持正义薄纱
github.com/TencentCloud/tencentcloud-sdk-nodejs/issues/160

下次给你安排虚幻引擎

已经不用 Node 了，现在小项目在选 Deno 和 Bun 。Bun 在 1.2 内置了 S3 和 Postgres 客户端，可以给项目做不少减法 bun.sh/blog/bun-v1.2

腾讯的 tencentcloud-sdk-ruby 也很搞，全是 java 的写法，看 21 年就有人给他们提过，结果到现在还是一样

好奇去看了下，src 目录和 tencentcloud 目录是大头。
src 下是 ts 源码，tencentcloud 下是编译过给 Node.JS 用的 CommonJS 代码。
然后里面主要内容在 services 里，有各种服务，平均 100k 左右，整个合起来就那么大。
然后 services 里面具体的有的会带日期命名的多个版本，应该是对应给不同版本的服务用的？如果确实不同版本同时有人用的话，那保留多个版本也还算合理？虽然更常见的做法是拆分不同版本的包，但是对于这种云服务 SDK 来说，我觉得放在一起问题不大。
然后里面最大的文件大部分都是 models 文件，是数据类型字段定义。然后大头是字段的 TSDoc 文档注释。

然后 CHANGELOG 有 5M 大小，内容大头是 commit history 。

src 和 tencentcloud 同时提供我觉得没什么问题，有些人倾向于直接 Node.JS require 使用，就用 tencentcloud 下的 CommonJS ，而有些人倾向于按需打包，用 src 会好一些（用 CommonJS 也不是不行，但 ts 源码更好）。
不过他们 src 下的导出方法有点问题，有多个版本的时候是 import 两个版本，然后 export 一个对象包含两个版本的 key ，这导致按需引用会出问题，总是会把所有版本都导入。
examples 和 tests 目录不算大，大部分库也会带着提供，提供不提供都行的。一般闭源的库会提供，开源的库你可以在项目托管的地方找到，就没必要提供。
CHANGELOG 也是大部分项目都会提供的，但开源的也确实同样没必要。

其它还好，版本号那里看笑了，是把前任发布工程师优化了，后来的野路子随便写了一个版本号吧，笑死

然后，楼主的运行方法，tsc 只是把 ts 转成 js ，还是会依赖 node_modules 的。
按需打包的话，相当于仅保留用到的代码，带上 tree shaking ，最终你用到多少代码就得到多少代码，还会去掉注释，这样 TSDoc 就都没了，最终产物不会很大。

推荐后端项目也通过 webpack 等 bundle 之后再部署。除非有些依赖不支持 bundle

感谢大佬写的如此详细。
我们只用了 typescript 转译，没有用其他的代码精简工具比如 rollup 。typescript 本身也会去掉注释之类的，但是不会动 node-modules 下面的东西。

后面可能会用 rollup 处理一下，不过暂时应该就将就了。

他们这 nodejs sdk 基本没文档，全靠看源码加猜来调试。

tencentcloud-sdk-nodejs 这个是主包，装对应产品的分包体积小很多。aws-sdk 下的应该没有包含所有产品，所以体积小很多

腾讯云有个 api explorer,可以查看每个产品接口的示例代码，看起来会方便点

＃26 文档的话，简单看了下他们的 TSDocs 貌似挺详细的？每个字段、函数的含义都有说明，在编辑器里鼠标移上去应该都有文档提示？
也有工具能够根据 TSDocs 生成统一文档站的。

没啥区别，你用 deno 或者 bun 调用腾讯云 sdk 也照样要用这个 85M 的 node_modules

可以使用 www.npmjs.com/package/clean-modules 清理

github.com/TencentCloud/tencentcloud-sdk-nodejs/issues/160

搂住这个是不是你啊
你火了啊

img
img

t.me/zaihuanews/30564

哥们儿，你火了哈哈哈

看走眼了，还以为只用了腾讯云的 cos 。要是用 deno 的话在代码目录就可以没有 node_modules 了，眼不见为净。

to 楼主，node 项目我以前用 pkg 打成二进制放容器里的，整个 Docker 镜像压缩后只有 60~70MB 左右，还挺好用

op 满级贴吧老哥阿，喷的笑死我🤣

腾讯好歹是国内 top3 的互联网公司，居然代码这么狗屎，世界还真是一个巨大的草台班子。。。😅😅😅

笑死了，刚去围观了一下

编译后增加了 2G ？

Python 版本装完 238M 。。。

原来是你发的，哈哈哈哈。这个 issue 彻底火了

看了一圈，发现腾讯云的 sdk 全写的不怎么样，我看了下 go 的也有人吐槽他们写的。ruby 那语法，但凡写过几天 ruby 的人都写不出来 ，不知道他们怎么写的，而且三年前提的，看了下到现在也没改，他们可能觉得那么写比较帅？感觉腾讯里的技术人才也应该不少啊，怎么能写出这么多有问题的 sdk 来，难道是外包的？

腾讯工程师和百度工程师 不少额外干着副业（虽然我很支持，提前给自己铺路）

像鱼皮这种，写公众号写面经教程如何进鹅厂，最后被 hr 劝退的

今天看了 Github 上的 Issue 之后，又回 V2 看了一下，果然是你，哈哈

原来是你

打包后的文件没有可读性, 所以很多 node 库也会把 src 打包进去, changelog 通常也是打包进去的, 只是这个 sdk 的文件体积实在太夸张了, 正常不会搞这么大.

你这嘴也是有才，打工人不骂打工人，除非憋不住 哈哈哈