node.js 和 VisualStudio 真的是构建 typescript 的唯一维护良好的选项吗？

Question

我在 windows 上的 eclipse 中工作。

我有一个包含多个项目的工作区，其中一个包含 typescript 和 sass (scss) 文件。我有一个有效的构建链，可以生成可靠的 CSS 和 JS 文件输出。然而，我在不久前创建了这个，我从来没有真正喜欢它一开始的设置方式。现在外部环境迫使我重新思考这个链条，我想重建它更加健壮。

我之前通过 nodejs 使用 webpack，从 eclipse 内部的 package.json 触发。 我不喜欢这样，因为我不喜欢依赖于生态系统的构建链的想法，这很难安全升级（没有明确的策略来恢复到稳定状态，以防出现故障或不兼容）。这正是发生在我身上的事情，也是我想离开这个设置的原因。

我想要的是：

• 我可以尝试手动升级/更新的（最好是更原子的）转译器的固定版本，但始终知道要使用旧版本。
• 不那么“凌乱”的链条，尽可能少的单个零件。
• 仍然保持解决方案。

我想到的是一个基于 Maven 的链，但这些方法似乎总是依赖于其他工具，而这些工具又使用 nodejs。我宁愿使用单独的构建链来构建 SASS，并拥有一个强大的 typescript 构建链。

Answer 1

official TypeScript compiler 是唯一提供类型检查的 TypeScript 编译器。这是一个 Node.js 程序。

Babel 和一些类似的工具也可以将 TypeScript 转换为 JavaScript，但它们所做的只是剥离类型注释（毕竟 TypeScript 语法只是 JavaScript + 一些现代 ECMAScript 特性 + 类型注释）。它对于生产构建非常有用且快速，但基本上违背了首先使用 TypeScript 的目的，这可能是类型检查。此外，我所知道的所有这种类型的工具也是 Node.js 程序。

这意味着编译器本身已经需要 Node.js。

主要来自 C/C++ 编程，我也不喜欢 JS 构建工具的特质，并努力避免它们。但它就是这样：如果你想使用 make、maven 或类似工具，你只能靠你自己。它也慢。 TypeScript（或 Babel）编译器是 Webpack 的进程中插件，但如果您使用通用构建系统，它将是一个外部命令。这会增加开销并导致编译器在某些设置中做一些额外的工作。最后，非常有用的 Webpack 功能（例如监视模式和开发服务器）在传统的构建系统中并不容易实现。

此外，我不认为你的反对是有道理的：事实上，如果你使用版本控制（无论如何你应该这样做）和package-lock.json，将 npm 包恢复到稳定状态非常容易文件。然后是git checkout stable-branch && npm ci 的简单问题。这里，ci 代表“全新安装”，它会安装所有版本号在package-lock.json 中的软件包。当package-lock.json 发生更改时，您甚至可以安装一个运行npm ci 的签出挂钩（您应该将其提交给您的版本控制系统）。

这样，您团队中的每个人以及您的应用程序的每个构建（无论是您的本地开发版本、您同事的开发版本、暂存服务器或生产服务器，或任何其他）都将针对给定的特定 npm 包git commit（或其他版本控制系统中的等效项）。