中午闲逛github, 看到某个项目的依赖不是最新的,就随手提了一个pull request (当然100%确保是兼容的). 不一会,收到反馈, 要求同步更新yarn.lock文件.
突然想到一个问题, yarn.lock是否要放到仓库中呢? 印象中这种文件, 需要的时候重新生成一份就行了, 感觉没必要放进仓库.
google了一下, 找到一篇, 直接翻译如下
Always commit your yarn.lock file into the source code repo
确保你的yarn.lock文件在代码仓库中
我用Yarn package manage来管理我所有的Angular项目. 因为它确实比npm要快. Yarn在运行时会创建一个yarn.lock文件用来保存所安装的依赖包的确切版本(ps, 代码中就怕这种不确定性, 这个锅npm得背). 去年, 我写了一篇博客, 里面描述了一个特定的场景, 造成我的一个Angular项目运行失败
I use the Yarn package manager for all my Angular projects. Besides being faster than npm, yarn creates a file yarn.lock that stores the exact versions of installed dependencies. Last year, I wrote about a specific use case that caused a breaking change during one of my Angular workshops.
昨天, 我不得不用Angular CLI创建一个新的项目. 项目创建成功, 启动也成功了. 然后, 我准备用ng build -prod 构建一个产线build. 然而失败了, 错误信息Cannot find module ‘uglifyjs-webpack-plugin’. 我知道, Webpack用UglifyJS来优化包的大小, 这很棒; 但是我的产线build构建失败了, 这很糟糕.
Yesterday, I had to create a new project using Angular CLI. The project was successfully generated and started with ng serve. Then, I wanted to create a production build with ng build –prod, but the build failed with the error Cannot find module ‘uglifyjs-webpack-plugin’. I know that Webpack uses UglifyJS for optimizing sizes of the bundles, which is great, but my production build fails, which is not great at all.
自动生成的package.json文件在我项目的根目录, 里面没有直接引用uglifyjs-webpack-plugin. 它静悄悄的呆在node_modules中, 是Angular CLI项目成千上万个引用中的一个.
The generated package.json file located in the root of my project has no direct dependency on uglifyjs-webpack-plugin, but there is one deep inside node_modules in one of the thousand (literally) dependencies used in Angular CLI projects.
长话短说, Webpack团队在npmjs.org中发布了这个插件的1.1.7版, 但是, 里面确实空的(ps, 算是发布事故吧). Angular团队跟进了这个版本. 一小时后, 发布了1.1.8版本修复了这个bug
To make the long story short, the WebPack team pushed to npmjs.org the new version 1.1.7 this plugin, which was empty. The Angular team got in touch with them, and an hour later, the fixed version 1.1.8 of the Webpack UglifyJS plugin was pushed to the npm central repo.
我项目中的yarn.lock文件锁定的是错误版本的插件. 我删除了它, 重新yarn. 这次 , 使用了1.1.8版本, *ng build –prod 成功了
My project already had the yarn.lock file with an erroneous version of this plugin. I deleted it and ran yarn install again. This time it picked up the fixed 1.1.8 version and the ng build –prod command started working again. Thank you, the Webpack team for the quick turnaround! Happy end!
这个问题的根本问题是在错误的时间创建生成了项目. 但想象一下, 在团队在同一个项目协作的过程中, 他们的代码仓库中, 没有包含引用1.1.6版本yarn.lock文件. 当QA决定构建工程时, 一分钟后, 你收到一封"Who broke the build?" 的邮件
This was a specific issue with the newly generated project created at the “wrong time”. But imagine a team working on a project for some time, and their github repo didn’t include the yarn.lock file that stored the reference to the working version 1.1.6 of that plugin, and Mary (the QA engineer) decided to make a production build. A minute later, the entire team got an email titled “Who broke the build?”
底线: 将可构建的yarn.lock文件push到代码仓库中, 来确保整个团队都有一个可返回构建运行的版本. 这样, 你的项目就不会因为npmjs.org中某个错误的提交导致构建失败
The bottom line: Push the yarn.lock of the project that works and builds correctly into your version control system to ensure that the entire team has a reproducible and working build. This way, your project won’t depend on someone from across the globe submitting erroneous packages to the npmjs.org.
P.S. npm5同样生成了一个package-lock.json文件来注册所有的安装的依赖. 但它不能保证每次npm install 都会安装里面的指定的包的版本
P.S. While npm 5 also creates the file package-lock.json with the registry of all installed dependencies, it doesn’t guarantee that each npm install will install exact versions of the packages listed there.
