这里归总下用npm来搭建前端项目中的一些感受
依赖包的管理问题
团队开发的话，必然会碰到这种依赖包的版本问题，团队各成员安装依赖包的时间节点不同，更新情况不同，会导致两个问题：
- 大家的依赖树结构不一样
- 大家的依赖包的版本不相同
问题1是npm3自身的设计引起的，其本身并不保证依赖树的结构是稳定可预知的，真的想达到这一点，可以强制要求变更依赖包的时候，大家统一进行删除node_modules目录，然后重新npm install这样的方式来保证。但是问题1即使不解决，也不会有大影响，最多就是有些人的版本目录相对冗余一些
但问题2就比较麻烦了，这是因为用npm install <pkg> --save默认写入package.json的版本规则是 ^x.x.x这样的，大家install的先后时间不同，就有可能导致最终安装的依赖包的版本不同；可能有些bug在新版本修正了，或团队有人使用新版本的新特性，这样一来，不同成员的机器上同样的前端代码就有可能出现不一致的行为；
因为写入 ^x.x.x 这样的版本规则是默认的，所以即使install的时候增加--save-exact参数来让顶层依赖包的版本固定，也解决不了次级依赖包的版本不一致问题；
所以还是保持大家统一使用默认的版本写入规则，然后定期团队统一进行update来维持版本的一致性（最好带上--save参数把package.json也更新一下来作为此次行为的更新记录）
dependencies和devDependencies的认识误区
发现网上的相当多文章和资料都简单地把package.json里用到的这两个字段：dependencies和devDependencies，认为是开发阶段要用到的工具和功能放到devDependencies，而量产后生成的代码运行所依赖的功能或框架放到dependencies里；所以会看到大家都倾向于把babel、webpack这些都放到devDependencies里去；
其实这是一个极大的误解，这两个字段里引用的包都是放到node_modules目录里的，在使用上没有任何的区别，比如你把jquery放到devDependencies里去，效果也是一样的，那为什么要引入这两个概念呢？
npm的官网其实已经给了我们正解，这是这个正解不是那么明确的给出来，只是简单的提到devDependencies是用来给那些测试依赖包或文档等等的；
devDependencies引入的真正原因是为了配合npm install --production命令，这个命令运行后，将只会安装package.json里dependencies字段给出的包；
所以到这里，我们可以明白dependencies字段的真正含义了：用于构建量产包的所需的最小依赖
而像webpack、babel这些都是构建量产包所必须的，所以应该是放到dependencies里才对！
网友评论