Node-RED 2.0

更改日志包含此版本中更改的完整列表，但这里有重点。此版本的主要重点是放弃对本身不再受支持的旧版 Node.js 的支持。这反过来又允许我们在内部进行一些主要的依赖更新。这需要时间和精力才能正确完成。因此，此版本中没有很多重要的新功能 - 但肯定有很多有用的东西可供使用。我们还发布了 Node-RED Flow Debugger 和 Linter 的第一个版本。这些是可选插件，可真正提升 Node-RED 编辑器中的开发人员体验。在我们讨论它们之前，让我们先看看 Node-RED 核心中的新功能。我们为 node-red 添加了一个新的命令行选项，以帮助您生成设置文件。它会询问您一系列关于您希望如何配置 Node-RED 环境的问题，例如设置用户安全性。这使得开始使用配置良好、安全的 Node-RED 环境变得更加容易。随着新的 node-red admin init 命令，我们重新组织了默认设置文件。设置现在处于更好的顺序，有更清晰的部分来帮助用户导航。

我们已更新默认设置文件，将流文件名硬编码为 flow.json。之前我们未设置它，因此运行时将使用主机名来生成流文件名。当人们在网络之间移动时，这会引起人们的注意。由于这是对默认设置文件的更改，因此所有现有安装将继续像以前一样运行。我们现在有对 Monaco 文本编辑器的可选支持。这在 Function 节点和其他地方提供了更丰富的代码编辑体验。目前，Node-RED 仍将默认使用 ACE 编辑器。要启用 Monaco，您需要编辑设置文件的 editorTheme 部分以包含这样的 codeEditor 部分：我们针对许多更常用的节点测试了此编辑器以确保它们与 Monaco 一起使用，但可能存在 contrib 节点那里假设编辑器使用 ACE。如果您遇到任何问题，请告诉我们，以便我们向模块所有者提出。为了让节点/插件更轻松地设置其 UI 元素的样式，以便它们遵循应用的任何自定义主题，我们添加了一系列 CSS 变量，它们可用于选取主题颜色。在上一个版本中，我们让 Function 节点更容易使用外部模块。在设置文件中启用后，您就可以配置 Function 节点在其编辑对话框中使用的模块。根据对该功能的反馈，我们在此版本中进行了以下更改：

该功能现在默认为新安装启用。要禁用它，您需要将 functionExternalModules 设置为 false。 UI 已经过重新设计，以提供更清晰的模块列表以及它们将作为哪些变量可用。我们已将安装模块的目录移回用户目录的顶层。这意味着只有一个 package.json 列出了您的所有依赖项。第一次运行 2.0 时，它会自动在新位置重新安装任何外部模块。 Inject 节点在其编辑对话框中有一个新按钮，它将使用编辑对话框中的值而不是当前部署的值来触发 Inject 节点。这使得在测试流的同时快速注入不同的值变得更加容易。请注意，主流程视图中的按钮仍会像往常一样注入当前部署的值。 RBE（按异常报告）节点是调色板的隐藏宝石之一。鉴于它在论坛上回答了多少次问题，很明显我们需要让它更容易被发现。在这个版本中，我们做了两件事：在幕后，它仍然使用 rbe 节点类型，因此现有流不会受到影响。这也意味着，如果您搜索 rbe，它仍会显示 - 因此遵循现有指南的用户仍会找到它。

给它命名过滤器应该可以帮助用户找到它并更本能地理解它的用途。它还打开了在未来添加更多过滤选项的选项，这些选项不会在“RBE”名称下安装。我们已删除 node-red-node-tail 作为默认依赖项。这意味着如果您的流程使用它，您可能需要手动安装该模块以恢复节点。一个新设置可用，fileWorkingDirectory 可用于定义文件节点用于解析相对路径的工作目录。如果未提供设置，节点将执行它们之前所做的操作 - 使用 Node-RED 进程的当前工作目录。在限速模式下，Delay 节点现在可以使用 msg.rate 动态设置其速率。 File In 节点有一个新选项可以在每行发送消息时包含所有属性 Exec 节点有一个新选项可以在 Windows 下运行时隐藏控制台窗口 现在可以告诉 Delay 节点使用以下命令刷新一定数量的排队消息msg.flush

使用 Node-RED 之类的工具进行低代码编程的好处之一是，它抽象了许多有关事物如何工作的技术细节。它使您可以专注于解决手头的问题。但仅仅因为它是低代码，并不意味着您不能拥有制作高质量应用程序所需的工具，并在事情不正常时帮助调试。为此，我们还为 Node-RED 发布了一对新插件，这将为整体开发人员体验带来重大变化。首先是一个 Flow Debugger。这就像常规代码调试器一样，但在流程级别。您可以在节点端口（输入或输出）上设置断点。然后，每当消息到达断点时，它会在该节点或整个运行时暂停。暂停后，它会向您显示在流程中的每个点排队的消息数量，并且在侧边栏中，您可以按照消息的处理顺序查看消息队列。从那里，您可以在流程中逐步执行每条消息，甚至可以在流程中将其删除。我们发布的第二个插件是 Flow Linter - nrlint。这可用于根据 linter 提供的大量规则来识别流程中的潜在问题。例如，如果您有未连接到 HTTP 响应节点的 HTTP In 节点，它会发出警告。或者，如果您的节点在物理上重叠并可能相互遮挡。我们在 eslint 之后对 linter 进行了建模，我们还将其捆绑在可用于对 Function 节点中的 JavaScript 进行 lint 的规则之一中。

我们将 linter 设计为使用 Worker 线程在浏览器中运行 - 这意味着它不会影响编辑器的性能。侧边栏向您显示 linter 结果，并让您快速导航到需要注意的流程区域。在编辑器之外，nrlint 也可以作为命令行工具安装和运行，用于处理流 json 文件。这意味着它可用于验证构建管道中的流。今天我们有一套最小的规则，最近来自社区的意见征集产生了一长串伟大的想法。我们确信会有一些更深奥的规则可能不属于核心集。例如，某些第三方节点可能希望介绍有关如何使用其节点的指南。因此，为了支持这一点，linter 规则是可插入的——允许创建自定义规则并通过 npm 与社区共享。我们去年发布的发布计划的目标是在 4 月底发布 2.0，之后每 3 个月发布一次具有里程碑意义的版本。鉴于我们已经比 4 月份的目标提前了三个月，我们需要重新审视我们的发布计划。 2.0 版本有点独特。这是我们的第一个主要版本提升，它解除了许多内部更改的阻碍，因为我们不再需要担心旧版本的 Node.js。但整理这些内部变化的时间比预期的要长，包括一些阻碍进展的上游问题。我们真的很想恢复到正常的发布节奏——有一个众所周知的可预测的发布日期，我们都在努力。这是我们在前进时会弄清楚的事情。但是今天，我们重新设置时钟并将注意力转移到将于 10 月下旬发布的 2.1。

如果您有兴趣在 Node-RED 中看到某个特定功能，那么现在是进入论坛并分享您的反馈的时候了。至于 1.x 流，它现在处于维护模式。这意味着如果有错误报告和可用修复，我们仍将在需要时发布维护版本。对于那里的贡献者，我们将围绕 github 中的代码分支进行调整，以反映我们现在拥有的不同流 - 我们将通过 slack 中的 #core-dev 频道分享更多详细信息，所以请过来打个招呼重新感兴趣。要对此帖子发表评论或留下反馈，请在 Twitter、论坛上联系或加入 Slack 上的对话。