IS-承诺验尸

上周六，我决定试着赶上我的开源项目中的一些贡献。我决定合并的第一个拉请求之一是向IS-Promise添加一个打字声明文件。

合并之后，我决定现在也是更新模块以支持ES模块样式导入的好时机。具体地说，我希望能够从IS-Promise导入isPromise，而无需启用合成默认导入。在此之后，我运行了测试，测试通过了，并发布了一个新版本。

我一直打算将我的更多项目设置为通过CI自动发布，而不是从本地机器手动发布，但由于IS-Promise是一个如此小的库，我认为可能不值得这么做。这绝对是个错误。然而，即使我设置了通过CI IS-Promise发布，也可能没有进行足够彻底的测试。

因为存储库有一个.npmgnore文件，所以我假设它在Package.json中不会有一个"；files"；数组，所以我没有更新该数组以包括新的index.mjs文件。

在将"；Exports"；字段添加到Package.json以告知较新版本的node.js有关ES模块版本时，我假设路径的工作方式与"；main"；相同，但它们需要./前缀。

我不知道"；Exports"；字段to Package.json不仅限制您可以导入的内容，而且限制您导入它的方式。因此，即使我的更改允许您导入index.js文件，如果您执行的是Required('；is-Promise/index'；)或Required('；is-Promise/index.js'；)，也会破坏您的代码。

我也没有考虑到Package.json中的"；Exports"；字段阻止您导入Required('；is-Promise/Package.json'；)。

从长远来看，出口限制可能是好的，但它们确实需要测试，他们使这一点发生了突破性的变化。

2020-04-25T15：03：25Z-I发布了IS-Promise的破碎版本。主要问题是Package.json中的"；Exports&34；字段。

2020-04-25T17：16：00Z-Ryan Zimmerman提交了一个拉取请求，为大多数人解决了问题。

2020-04-25T17：48：00Z-我收到一条Facebook消息，要求我查看GitHub。这是我意识到有些不对劲的第一点。

2020-04-25T17：54：00Z-I合并并释放Ryan的拉取请求。对于大多数人来说，这修复了库，但许多人仍然有缓存的版本，有些人通过"；导出"；在Package.json中现在阻止的奇怪路径导入。

2020-04-25T17：57：00Z-在阅读了各种问题评论后，我将它们全部关闭，并创建了一张新的罚单，以便我们可以进行更有成效的讨论。

2020-04-25T18：06：00Z-乔丹·哈班德向我解释为什么出口仍然是一个突破性的变化。

2020-04-25T18：08：08Z-I从Package.json中完全删除"；exports"；并发布修复版本。

2020-04-25T19：20：00Z-I取消发布损坏的版本，试图强制拥有锁定文件的任何人从这些版本进行更新。

从我的本地机器释放总是让人忍不住跳过创建拉请求和让CI测试我的更改的重要步骤。

我们的测试只覆盖了实际的代码，没有检查发布到NPM的内容。

在这起事件中，我并不容易联系到。尽管GitHub存储库上有多个贡献者，但他们没有部署新版本的权限。

在这件事之后，我决定把一切都设置得尽可能健壮。我还决定，最安全的做法是将所有这些更改作为新的主要版本发布，以避免破坏人们的东西，即使他们正在使用未记录的方法进行导入。

在过去的几个月里，我一直在构建Rolling Versions，这是一个帮助您通过持续集成安全地发布包以及重大更改日志的工具。我现在已经将此添加到IS-Promise中，这给了我对未来版本的更大信心。

从持续集成中释放是您可以做的最重要的事情之一，以帮助防止类似的事件。编写更改日志也是帮助您检查自己的更改并考虑其影响的一种非常有效的方法。这实际上只有在您将更改日志作为拉入请求的一部分写入时才有效，而不是在事后写入更改日志。当我从事后(<；3.0.0)编写到作为拉请求(https://github.com/then/is-promise/releases 3.0.0)的一部分编写它们时，您可以在更改日志中看到详细的增加：≥。

如果您想了解更多关于Rolling Versions的信息，或者想了解我对软件开发和开源的最新想法，您可以在这里订阅我的邮件列表：