vue-cli3.0 启动时端口随机是谁的锅？

前言

昨天更新了以下vue-cli版本3.10.0，然后导致vue-cli有个更改服务端口的功能无法使用了，官方github有issues。

这种属于严重bug了吧，核心功能无法正常使用。

所以就有些好奇，像这种规模比较大，影响比较广的项目，如果发生了严重bug，造成bug的人是否有责任？

人家无偿贡献，你爱用不用，没人逼你用，很对。但又觉得吧，好像不太对，毕竟影响力这么大，受众这么多，真有啥问题的话，也挺严重的。所以就比较好奇，来问问，像这种开源项目都是怎么管理的？

造成的原因

首先说明一下，这不是 Vue CLI 自身的 bug，而是上游依赖 portfinder 的 bug，不仅是 Vue CLI，包括 Ember CLI 在内的很多项目都受了影响，这个库也是 webpack-dev-server 的一个依赖，我还没测试过不确定 webpack-dev-server 有没有受影响。不过，这个问题暂时只是给开发带来了一点点不方便，不影响生产环境，应该不算严重 bug。

portfinder 的 bug引起的反应

知乎上：
开源社区的很重要的价值就是，让项目在更多人眼里“review”，越多人关注，出现bug的可能性就越小。我认为只要是代码总会有bug,只是暴露的方式不一样而已，所以我们要正确对待，开源吗？是为了我们码农的进步，没有必要去做喷子。

每个版本是否会严格测试？当然会，必须会。首先，Vue 的代码仓库里就有数千个测试用例，每个 PR 和提交都要过一遍所有已有的代码风格测试、类型校验、单元测试、覆盖率测试、集成测试等等，其中集成测试会在多个浏览器平台上各跑一遍。并且，每个 Bug Fix 和新增功能的 PR 都必须添加对应测试用例。事实上，这类被直接广泛使用的开源项目，测试代码一般都远多于实现功能用的代码，有时甚至还会因为测试太多、运行时间过长导致测试成了项目开发的一个瓶颈。对于影响力较大的项目，单是与项目代码放在一起的单元测试、集成测试有时还不够，需要在更实际的环境里进行回归测试。比如 Vue 就有 regression-testing 仓库，每个合到主干的提交，都会在生产环境下，对下游影响力较大的开源仓库进行回归，再次确认内部的变动不会影响到社区用户。再然后，尽管前端的自动化测试已经非常成熟，但大型开源项目一般还会在本地手动过一遍测试，再次以防万一。比如 React 团队之前的一篇博客就提到过，他们会有一些测试用例是专门在本地人工测的。Vue CLI 的 Cypress 相关测试也会在 CI 环境和本地环境各跑一遍，CI 环境用 headless 模式，本地则是打开 GUI 界面人工点击（因为之前碰到过 headless 模式和常规模式运行结果不一致的 bug）。除了开发流程上的这些手段保证以外，发布流程上，这类项目也会在正式版发布之前先发布多个版本的 pre-release 版本，供核心用户（以及想尝鲜的用户）提前测试兼容性，如果碰上问题可以尽早反馈，在正式版发布之前修掉。比如 Vue 2.6 就有提前发过 3 个 beta 版，而 Vue CLI 4 目前已经发了 6 个 alpha 和 4 个 beta 了，即使在前述种种测试机制下仍有 Bug 漏网，在这个阶段也一般都能测出来并修复。（补充一点，发布流程本身也是要有测试的。比如，Vue CLI 发布前一般都会在本地的 verdaccio registry 上验证一遍发布流程）写了 Bug 是否会有人受惩罚？如果在这样严格的测试流程下仍出现 Bug 的话，这种 Bug 一般只能说是非战之罪了，跟写 Bug 的人本身关系不大，我们更多要反思的是设计问题。比如题主所说的这个问题，本质上就不是 Vue CLI 的代码问题，而是 NPM 社区的信任问题，我们真正要解决的是，如何应对不靠谱的第三方包维护者？用户都是用脚投票的，每当一个第三方包出现重大 bug，社区对它的信任就会减一分。很多注重稳定性的用户要么会选择不用这个包，自己实现（比如 left-pad 事件后，虽然官方恢复了 left-pad 包，但大家也纷纷自行实现 left-pad 算法），要么就选择锁定依赖版本，只用确定靠谱的依赖（但当前靠谱的依赖未来不一定靠谱，锁定版本会导致无法自动更新 security patch，不推荐）。而对于开源项目来说，没人用这个库就已经是最大的惩罚了。但是，依赖问题不应该是开源库自身来解决的。如果每个库都自己实现每个功能，那么就会出现大量重复工作，开源社区的意义就少了很多；而如果每个库都锁死依赖版本号，那语义化版本号的存在也就没什么价值了。所以，依赖的信任问题必须在应用层面解决。而现在 Node 社区已经有很多对应的解决方案了。比如，对于临时处理有问题的依赖版本：cnpm 有一个 bug-versions 仓库，收集了各个知名项目有问题的版本号，这样即使当前最新版是有问题的，用户在使用 cnpm 安装依赖时，也可以避开这个版本，直接安装到最近一个确保可用的版本；yarn 支持在 package.json中通过 resolutions 字段指定某个依赖的版本号，用户可以对间接依赖的版本有更精确的控制。比如题主碰到的问题就可以通过在 package.json中添加以下内容并重新运行 yarn解决：“resolutions”: { “@vue/cli-service/portfinder”: “1.0.21” } npm 有 npm-force-resolutions 实现相同功能；pnpm 有 hooks 机制解决类似问题。而更为重要的长效机制，则是通过在项目代码的版本管理中加上 lockfile，确保项目每次构建的时候严格根据 lockfile 中的版本号安装依赖（npm ci或者yarn install --frozen-lockfile）。这样，只要你开发时不出现问题，项目上线的时候就不会出问题。最后，Vue CLI 作为一个帮助大家快速搭建项目环境的工具，我们也不希望用户总是时不时被这种依赖问题烦恼到。尽管有前述种种应用层面的解决策略，在上游依赖出现重大 bug 时，Vue CLI 也会发布紧急的 hotfix 版本（比如这个由 webpack 更新触发的 npm bug）。此外，我们也一直有在研究如何直接在工具的设计层面，更好地帮助用户管理项目依赖，避开社区的种种坑。不过，稳定和自由总是难以兼顾的，希望能在不远的未来找到一个比「锁定版本号」更好的平衡点。
…

知乎上有篇文章这样写道
像vue这种开源项目，有人写了严重bug，是否会有惩罚？每个版本是否会严格测试？

解决方法

我们找到问题的根源，这个根源是什么呢？就是portfinder版本太高不兼容的问题，所以我们只需要portfinder降级就行啦，

npm i -D  portfinder@1.0.21

其他的解决方式