http://yehudakatz.com/2016/10/11/im-excited-to-work-on-yarn-the-new-js-package-manager-2/

Babel 和 Ember 两家主创携手奉献啊（还有 Google FB），在主流的 JS 框架里头，估计俺大 Ember 又一次要走在前面了。

哈哈哈，所以不是我一个人讨厌 NPM 的机制！

时常出现获得一个 Warning，说正在用的某个 NPM 版本存在漏洞需要更新，然而我根本没法找出是谁依赖，因为 NPM 这个依赖设计是这样的：

package_a:
   xxx 0.1.0
package_b:
  package_bb:
     xxx 0.2.1
package_c:
   package_cc:
      package_ccc:
         xxx 0.3.0

以及一个稍微大点的项目 node_modules 占个 1G 是很正常的事情。

Yarn 配置国内 NPM Mirror

$ echo 'registry "https://registry.npm.taobao.org"' > ~/.yarnrc 

好东西呀，给 npm 版本控制坑了好多次，现在我们 package.json 几乎都直接写死版本。

wycats 正著手解決 yarn.lock 痴肥的問題

https://github.com/yarnpkg/yarn/issues/579

链接知乎的讨论：

https://www.zhihu.com/question/51502849

不過還是用了 .lock，用 .locked 可能好些

https://github.com/bundler/bundler/issues/694

好处就是 yarn.lock 锁定版本，npm 这个问题很严重。

安装上是有很大进步的，有一个 repo 的地方。

总的来说，我觉得没什么大的变化。跟 npm 区别并不大。可以替换 npm 但并不解决本质问题。

yarn 还是解决不了一些最基本的依赖问题，yarn install --flat 的时候有冲突其实你还是无能为力，其实需要用户自己去 resolve dependencies, 这个过程就很麻烦了。而且这个只能靠社区来推动，因为你也处理不了两个包依赖的 underscore 版本不一致类似这样的问题。

真的要解决这个问题，其实应该从本身 npm 的社区的类库入手，像 small focused modules 这种东西，在有新的 ES6 tree-shaking 技术支持的情况下，这里应该像其他语言类库，类似 Ruby 一样变成相对大的类库。这样在打包的时候 resolve dependencies 才有意义。不然装一个 react, 依赖了成百个包。这成百个包都有可能会升级，会依赖。你怎么 resolve dependencies… 基本是不可能的任务。

我心目中理想的 JavaScript 工程化应该是 Yarn + rollup + small focused modules, 这个估计是办不到了。

所以，我现在还是会用 url download + concat + order 的方式来打包自己的类库，手动 resolve dependencies.

毕竟在做产品的过程中，还是比较关注打包后前端的文件引用的大小，自己控制依赖比打包好后去发现文件为什么这么大成本低多了。

Getting Started 第一行

$ npm install -g yarn

JS 从听说到放弃

#12 楼 @lokyoung 你看错地方了，是 shell 脚本安装的

JS 今年太疯狂了。。。

找个时间试试。现在觉得 lock 还是很必要的。以前我还写了个回复说依靠 SemVer 自我约束就行了，但自从搞了 React 之后我再也不相信 SemVer 了。现实中很有一部分 npm 包遵循的是这种规则：

• 0.x.y 版本，x 就是 breaking change，y 才是 bugfix。到了 1.0 在遵循 SemVer 不迟。
• x.y.z 版本，基本还是遵循 SemVer 的

不过，我还是觉得 npm 推崇的 nest dependency 是有价值的，它可以让间接依赖变得更加灵活，从而可以让直接依赖少点限制。

#14 楼 @i5ting 嗯，后来看了下是通过 shell 装的。不过也提供了 npm 的方法就是了。

#16 楼 @darkbaby123 233 我早就说过了，我是被 Radium 坑得惨，后来在没法构建的情况下把这个依赖整个去掉了

#11 楼 @Saito 可以把这些 small focused module 全部 concat 成一个包，叫 big-focused-module ...

最理想的包管理应该是支持两种 dependency:

• 一种是计算出一套相容的 package version, 载源文件
• 如果实在没法相容，可以选择让某些 package 直接载编译好的而不载入源文件

但如果一个包有全局副作用，就不能允许它多个版本同时存在了...

#19 楼 @luikore 早些年有人投入 compressor 事业，也不会有 small-focused-module 这种事.. 主要还是那些人在瞎搞事...

@Saito 问题是 tree shaking 需要静态分析模块依赖来支撑，目前只有 ES module 能做到这点。而 Node.js 因为入 CommonJS 的坑已久，迟迟不能支持。这个问题不是短期能够解决的，而且要把大部分 package 重新用 ES module 的方式写也不现实。前端因为有预处理器，受这个的影响反而很小。

其实我就只希望 yarn 能锁定版本，是不是像 Bundler 一样 flat dependency 不是那么重要。拿“两个包依赖的 underscore 版本不一样导致无法顺利安装”的例子来说，反过来想应该是“我想用的只是 A 和 B 但并不在乎它们有什么依赖，为什么它们的依赖要对我产生影响？” 。这也是另一种 dependency hell。如果能用一点多余的空间解除一些依赖的限制，也是值得的。如果这样想的话，会发现 small-focused-module 就比 big-focused-module 更有利（占的空间更少）。

#21 楼 @darkbaby123 所有语言都可以不在乎依赖对项目产生的影响，偏偏 JavaScript 不行... 哪天干掉浏览器其实也行，因为别的用 JavaScript 的地方其实也不在乎大小依赖这件事..

#22 楼 @Saito 相比服务端，客户端确实更在乎大小，所以尽量不要载入重复的包。不过如果像 Webpack 那样推崇从源码编译打包的，每个模块（文件）都是依赖，成百上千，这时候其实只要通过一些手段（比如 dedupe）去重后，最终容量在一个可接受范围，也不会太 care 有没有重复。也许还是会有一点重复，但人工成本省了很多，还有其他诸多优势，也是一种权衡。