JavaScript Yarn: A new package manager for JavaScript

Rei · 发布于 2016年10月12日 · 最后由 darkbaby123 回复于 2016年10月15日 · 2741 次阅读
1

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

共收到 23 条回复
1573

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

De6df3

哈哈哈,所以不是我一个人讨厌 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 是很正常的事情。

De6df3

Yarn 配置国内 NPM Mirror

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

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

1510

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

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

1510

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

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

243

好处就是 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… 基本是不可能的任务.

243

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

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

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

20875

Getting Started第一行

$ npm install -g yarn

😂 😂

1553

JS 从听说到放弃

5173

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

4209

JS今年太疯狂了。。。

2575

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

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

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

20875

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

23529

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

2880

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

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

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

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

243

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

2575

@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 更有利(占的空间更少)。

243

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

2575

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

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册