Why upload node_modules folder?

[jkiss]

RT

[bgdsh]

看起来是内部的package。

[Nihiue]

内部package不是提交node_modules 的理由吧，还是腾讯的规范是所有项目都提交node_modules？

[huangyoukun]

TSW对外部依赖分级为三级

1.核心依赖 -- 缺少会影响运行

2.非核心依赖 -- 不影响运行，某些工具才会用到的模块

3.业务代码依赖 -- 和TSW无关，只是业务需要或demo运行需要

TSW源码涉及的node_modules罗列如下

1.TSW/bin/node_modules

2.TSW/node_modules=TSW/package.json

3.TSW/examples/framework/node_modules =TSW/examples/framework/package.json

其中2和3都是声明在package.json中的，可通过npm命令补齐依赖。

2和3这里就不讨论了，重点讨论下1这种情况

其中1属于核心依赖，使用了内置的方式，主要是出于以下考虑

用户维度

1.运维同学并不全是npm用户。安装TSW部署过程依赖npm并不是个好的运维体验。对于运维同学来说，TSW更像是一个包，而不是一个模块。通过物理变更就部署完成，是运维角色很合理的诉求。

代码组织维度

1.从定位上来说，TSW并不是一个模块。和业务的结合点是配置文件，并不是node_modules。TSW和业务代码不用挤在同一个node_modules下，在互不相干的两个目录下就可完成配合 。

2.基于上面这点 ，TSW目录下放什么样的模块，对业务的node_modules是无感的，也不影响业务代码使用第三方模块的灵活性，更不会冲突，TSW可以独立于业务代码迭代 。

代码升级维度

1.核心依赖，随着TSW版本一起升级，对依赖的变更一起管理，符合谁使用谁治理的运维思维

模块寻址维度

1.node_modules目录对其子孙目录有协助寻址的功能，这里只是利用了这一Node.js最基本的机制。对寻址机制加以利用，完成自己诉求，是开发人员独立思考的本能。NPM也是利用了这一机制。node-v0.6.0没有npm的时候，这个机制就存在了，这个目录使用权并不是npm特有的。

[int64ago]

TSW对外部依赖分级为三级

1.核心依赖 -- 缺少会影响运行

2.非核心依赖 -- 不影响运行，某些工具才会用到的模块

3.业务代码依赖 -- 和TSW无关，只是业务需要或demo运行需要

所以要合理用好 dependencies/devDependencies/peerDependencies 啊

运维同学并不全是npm用户

都用 Node 了，怎么会没有 npm

核心依赖，随着TSW版本一起升级

如果是使用了核心依赖里利用了带有 C++ 模块的 npm 包呢？岂不是你们需要按不用平台分发？而你们并没有

---

以上是看到你的表述不认同的，下面再说说很明显的几个坏处

• 对你们的开发人员不方便，如果安装包的时候使用了软链的方式，分发到 GitHub 上的很可能只是一个软链符号
• Code Review 几乎没法进行，你们每次包的更新要看一坨无关紧要的 node_modules ？
• 对用户不利，大多数用户本地 npm 网络压力（很多包已经有缓存了）一定比 GitHub 直接拉这么多文件要小
• ...