ReScript 8.4

ReScript是一种声音类型丰富的语言，具有针对JS平台的优化编译器，它专注于类型安全性，性能和JS互操作性。它曾经被称为BuckleScript。

大约在四年前作为构建系统引入时，我们假设依赖项是不可变的，因此，在第一次构建依赖项时，我们就不再需要对其进行重新构建。当假设不成立时，的完整性将被破坏。

在此版本中，我们修复了允许用户更改依赖项的完整性。此修复程序很好地实现了不进行此类修改的人员不会为此付费的目的。

这是基于用户反馈的最高期望功能请求之一，因此我们将在此处扩展一些为什么在不牺牲性能的情况下很难实现的请求。

在ReScript编译方案中，将软件包的依赖项视为黑盒，依赖项的更改应是可传递的。这是由于我们具有跨模块优化功能，并且二进制接口本身是其依赖项的哈希。因此，对于包依赖项链： B-＆gt; C，如果A更改而B不变，则C仍需要重建。由于B的中间输出可能仍会由于A的更改而发生变化。更糟糕的是，每个软件包都附带一个安装过程，该过程是一个Shell脚本，因此重新安装将使程序包看起来像刚构建的。

在此发行版中，我们还跟踪构建图中的安装，并计算依赖项安装的哈希值，并将其放入用于构建二进制工件的依赖项命令行标志中。这样的策略在以下方面有好处：

安装散列的计算几乎是免费的，因为它只是一个统计信息，我们不需要跟踪所有依赖项。文物。

此类哈希的引入不会出现在解析中，因此依赖项的更改将永远不会触发重新解析。

打包安装完成后，将断开传递重建图，以便我们可以节省一些不必要的重建。

当人们对依赖关系进行更改时，如果此类更改不更改包接口，它将不会触发其依赖关系的建立。

为了更加实用，我们还引入了一个新概念：。通常，包分为三类：

以前，我们只有和，通过引入，这样的软件包将像软件包一样被构建。

用法非常简单，请添加到顶级包中。请注意，此类字段仅在顶级配置中才有意义。

当人们删除或重命名脚本文件时，它将引入陈旧的输出，例如，重命名将带来（以及更多中间输出）陈旧。这比听起来要糟，假设您有一个隐藏在stdlib列表中的本地对象。现在我们将其删除，它将引入陈旧的文件，而没有适当地删除此类过时的文件，此类陈旧的文件将破坏构建的完整性。

在此版本中，我们引入了一种更强大的算法，该算法将始终在构建之前删除过时的输出，以免破坏此类完整性。 最后但并非最不重要的一点是，我们将继续提高生成的输出的可读性和可调试性：）