-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
【译文】Yarn 的确定性 #3
Comments
原文中的 hoisting 一词,这里翻译为了“提升”,但总感觉不准确,有了解的还请赐教 |
这篇文章里提到的 hoisting 和 JavaScript 中的 hoisting 应该是一个意思,译成「提升」没毛病,参考资料 MDN |
👍 |
我觉得通过 yarn.lock 文件也是能推断出
这个例子中,我们能得出顶层目录是
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
原文:https://yarnpkg.com/blog/2017/05/31/determinism/
Yarn 提出的其中一个观点是它让包管理变成确定性的。但这到底意味着什么呢?这篇博文突出说明了 yarn
和 npm 5是如何保证包管理是确定性的,并且指出它们提供的确切保证和做出选择的权衡点的不同。
什么是确定性
在 Javascript 包管理的背景下,确定性是指在给定的 package.json 和 lock 文件下始终能得到一致的 node_modules 目录结构。
Yarn 确定性的保证因素
Lockfile
只要使用相同的 yarn 版本,yarn 就是完全确定性的。在 yarn 和 npm 5 中,确定性是由 lockfile 文件确保的,lockfile 包含了整个依赖树的信息。然而,在 yarn 和 npm 5中,lockfile 的文件格式是不同的。我们从来没有公开谈论过为什么使用这种格式,这里我们会带你一起看一下。
如果你曾经看过 yarn.lock 文件,你应该对下面的这种结构感到很熟悉。
这是通过运行命令
yarn add supports-color
而产生的 yarn.lock 文件。这个文件包含了supports-color
和 它的子依赖has-flag
的确切版本。使用这个 lockfile 文件,我们可以确定
supports-color
依赖的has-flag
总是使用相同的版本。但是 lockfile 文件缺少一个关键的信息,那就是依赖树上的每一个依赖的 提升(hoisting) 和 位置。比如,给定一个 yarn.lock 文件是不可能确定顶层依赖的,除非同时拥有 package.json 文件。即使知道了顶层依赖,我们仍然无法推断出应该依赖装在什么位置。
实际上,这意味着在 node_modules 目录中 package 的位置是在 yarn 的内部计算出来的。这就使得在使用不同版本的 yarn 时可能会引起不确定性。
我们这样做的原因是 这种 lockfile 文件的格式对 比对(diffing) 是非常有用的。也就是说,对 lockfile 的修改很容易被人审查。我们使用自定义格式而不是JSON,并将所有内容都放在顶层,这样便于阅读和审查。合并冲突通常由版本控制自动处理,这样就可以减少冲突。
提升保证
尽管在不同的版本中,yarn 提升可能会有所不同。但在使用相同版本的 yarn 时,我们仍然会对提升进行强有力的保证。这些保证中最重要的是忽略诸如 optionalDependencies 和 devDependencies 这样的会影响正常依赖关系的位置的环境依赖。
这实在有些让人难以理解,那到底是什么意思呢?
在 package.json 文件里你可以声明多种类型的依赖。其中两个,一个是始终会安装的简单依赖,另一个是只有在 package.json 目录下运行
npm install
和yarn
才会安装的 dev 依赖。由于这些特性,在忽略了某些依赖后可能会导致不同的 node_modules 目录结构。但是在确定依赖在 node_modules 中的确定位置时,yarn 仍然会把所有的依赖考虑在内。即使有些依赖没有被安装,他们仍然会影响其他依赖的提升位置。这一点很重要,因为在生产和开发环境中,包的提升位置有差异会导致非常奇怪的 bug。
注:这个保证不是 yarn 唯一的,npm 5 也是这样做的。
和 npm 5 比较
npm 5 引入了一个称为 package-lock 的类似 shrinkwrap 特性的 设计。package-lock 文件包含了创建node_modules 所需的所有信息以及所有的提升信息。先前的 yarn.lock 文件的 npm 版本是如下的结构:
注意,在第一个 dependencies 对象里列出的所有依赖都是提升的。这就意味着 npm 仅仅使用 package-lock 文件就可以确定最终的依赖关系图,而 yarn 却需要相应的 package.json 文件。
这意味着 npm 可以更好地保证在 不同的 npm 版本中提升位置,而代价是拥有一个更密集的锁文件。对于 yarn 来说,关于 lockfile 的互操作性还不是很清楚,所以目前还没有关于如何支持 package-lock 的计划。但是,你可以想象在将来 yarn 会同时支持和更新他们。我们对社区的反馈非常感兴趣,并鼓励人们就如何将其作为RFC提出建议。
小结
每个 lock 文件格式都有不同的考虑方案,而且似乎没有完美的格式。在决定使用什么包管理器时,评估你需要什么样的保证是很重要的。
npm 5 具有更强的跨版本的保证,并且具有更强的确定性锁文件。但是只有当你使用同一个版本时,yarn 才有这些保证,因为这样会更有利于一个更轻量的锁文件以及更好的审查。很可能会有一个更好的 lockfile 的解决方案,但是 yarn 和 npm 5 的锁文件代表了当前的状态,并且可能在未来发生融合。
希望这篇文章让您了解 yarn 和 npm 之间的确定性保证的不同,并帮助您决定什么对您的公司或项目更有效。
The text was updated successfully, but these errors were encountered: