Why upload node_modules folder?
jkiss opened this issue · comments
RT
看起来是内部的package。
内部package不是提交node_modules 的理由吧，还是腾讯的规范是所有项目都提交node_modules？
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特有的。
TSW对外部依赖分级为三级
1.核心依赖 -- 缺少会影响运行
2.非核心依赖 -- 不影响运行，某些工具才会用到的模块
3.业务代码依赖 -- 和TSW无关，只是业务需要或demo运行需要
所以要合理用好 dependencies/devDependencies/peerDependencies 啊
运维同学并不全是npm用户
都用 Node 了，怎么会没有 npm
核心依赖，随着TSW版本一起升级
如果是使用了核心依赖里利用了带有 C++ 模块的 npm 包呢？岂不是你们需要按不用平台分发？而你们并没有
以上是看到你的表述不认同的，下面再说说很明显的几个坏处
- 对你们的开发人员不方便，如果安装包的时候使用了软链的方式，分发到 GitHub 上的很可能只是一个软链符号
- Code Review 几乎没法进行，你们每次包的更新要看一坨无关紧要的 node_modules ？
- 对用户不利，大多数用户本地 npm 网络压力（很多包已经有缓存了）一定比 GitHub 直接拉这么多文件要小
- ...