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

Question

我在 Windows 上的 Eclipse 中工作。

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

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

我想要的是：

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

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

标签： windowstypescripteclipsesass

Answer 1

官方的 TypeScript 编译器是唯一提供类型检查的 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. 您甚至可以安装一个结帐挂钩，该挂钩npm ci在发生更改时运行package-lock.json（您应该将其提交给您的版本控制系统）。

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