JavaScript Yarn: A new package manager for JavaScript

Rei · October 12, 2016 · Last by darkbaby123 replied at October 15, 2016 · 7372 hits

https://code.facebook.com/posts/1840075619545360

Hacker News:

https://news.ycombinator.com/item?id=12684980

TLDR:

lockfiles 锁定版本,全局缓存避免重复下载。

我最喜欢的评论:

Bundler makes almost all the right choices already. Its major disadvantage is that it only works for Ruby. link

联动:

npm 没有 Gemfile.lock 这样的机制,怎么想的? https://ruby-china.org/topics/29777

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

不過還是用了 .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 有没有重复。也许还是会有一点重复,但人工成本省了很多,还有其他诸多优势,也是一种权衡。

You need to Sign in before reply, if you don't have an account, please Sign up first.