Rush StackShopBlogEvents
跳到主要内容

Heft架构

先读这个 🎈​

以下是 Heft 最重要的一些概念的快速总结：

Action​

在 Heft 的术语中，"action"是命令行动词，由 Rush Stack 的ts-command-line系统规范化。使用heft --help来查看可用的 actions。clean和run actions 是由 Heft 本身提供的；其它的是由你的heft.json配置生成的。

例子：一个 shell 命令heft test --clean正在调用test action。

注意：Heft 的早期版本也使用"action"这个词来表示heft.json中的eventActions。这个术语现在已经不再使用。

Parameter​

Actions 支持各种命令行"parameters"以调整行为。一些 parameters 是由 Heft 本身定义的；其他的是由 Heft plugins 贡献的。

例子：一个 shell 命令heft test --clean正在使用--clean parameter。

Task​

Heft "tasks"在你的项目的heft.json配置文件的tasksByName部分中定义。Tasks 通常读取输入文件和/或生成输出文件，通常通过调用如 TypeScript 或 ESLint 这样的熟悉的工具。每个 task 加载一个 Heft task plugin（见下文）。两个不同的 tasks 可以加载同一个 plugin。Tasks 可以相互依赖，这决定了调度顺序。

例子：@rushstack/heft-web-rig配置定义了一个名为webpack的 task。

Phase​

"Phase"是 Heft tasks 的一种安排，定义在你的项目的heft.json配置文件的phasesByName部分。在该文件中，phases 被赋予如build或test等名称。定义一个 phase 会创建两个对应的命令行 actions。例如，test phase 会产生一个heft test和heft test-watch action。-watch变体用于交互式的观察模式，例如本地开发服务器。

如果 tasks 属于同一个 phase，它们可以共享内存对象进行优化；否则，它们只能通过将文件写入磁盘进行通信。这个要求支持与Rush phases的集成，后者可能在不同的时间或在不同的计算机上运行，通过 Rush 构建缓存进行通信。

例子：@rushstack/heft-web-rig配置定义了一个包含webpack task 的build phase。

Plugin​

Heft plugins 是实现IHeftPlugin合约的 TypeScript 类。有两种类型的 plugins：

  • 一个task plugin可以被heft.json tasks 加载，并提供他们的实现
  • 一个lifecycle plugin提供了不特定于任何 task 的通用功能；例如，收集时间度量

Plugin package​

"Plugin package"是提供 Heft plugins 的 NPM 包。NPM 包的命名模式是heft-____-plugin或heft-____-plugins（根据 plugins 的数量）。内建的 plugins直接从@rushstack/heft包中加载。

请查看Plugin package index以获取官方 plugins 的列表。

例子：@rushstack/heft-jest-plugin包实现了jest-plugin。

Plugin manifest​

每个 plugin package 都包含一个名为"plugin manifest"的文件heft-plug.json。它描述了可用的 plugins，他们的选项，以及他们的命令行 parameters。Heft 是数据驱动的，这意味着这样的信息可以在不执行任何自定义脚本的情况下被发现。(尽管脚本配置非常流行，但它有许多问题，比如意想不到的性能成本，妨碍缓存的不可预测的行为，以及糟糕的错误信息。)

例子：@rushstack/heft-jest-plugin包在这个 manifest中声明了jest-plugin。

Hook​

Heft plugins 可以为构建生命周期中的各种事件注册处理程序。"tapping"事件"hooks"的 API 术语来自于 Heft 的tapable系统的使用，这在 Webpack plugins 中很常见。

例子：在 Heft 的源代码中，IHeftTaskHooks接口公开了一些 hooks。

Rig package​

Heft 的主要理念是将构建逻辑移到 plugin packages 中，这样你的构建过程就是由 config files 而不是 program scripts 定义的。在大型的 monorepo 中，这极大地降低了维护成本，通过确保 program scripts 作为专业软件进行开发，而不是作为.js文件中的特设命令。

Rush Stack 的rig system更进一步，可选地将 config files 移动到一个名为"rig"的集中 NPM 包中。Rigs 为你的项目定义标准化的配置。在大型的 monorepo 中，他们规范了你的构建团队已经同意支持的配置。Heft 还允许从 rig packages 解析devDependencies，减少了package.json的混乱。

例子：@rushstack/heft-web-rig是 Rush Stack 为 web 项目的参考 rig。

Rig profile​

单个 rig 包可以为特定目的提供多个"profiles"。rig 包中的 profiles 共享相同的 rigged devDependencies，并且可能通过"extends"继承共享配置。

例子：@rushstack/heft-web-rig rig 包目前定义了two profiles，app和library。