如果 esModuleInterop 是 true 配置 TypeScript 转换，我是否需要明确的 allowSyntheticDefaultImports？答案

【问题标题】：Do I ever need explicit allowSyntheticDefaultImports if esModuleInterop is true configuring TypeScript transpilation?如果 esModuleInterop 是 true 配置 TypeScript 转换，我是否需要明确的 allowSyntheticDefaultImports？
【发布时间】：2019-03-05 16:24:03
【问题描述】：

我需要确认以下理论。根据TS docs，在tsconfig.json中可以设置两个选项。

--allowSyntheticDefaultImports： 允许从没有默认导出的模块进行默认导入。这不会影响代码发出，只是类型检查。
--esModuleInterop： 发出 __importStar 和 __importDefault 帮助程序以实现运行时 babel 生态系统的兼容性，并启用 --allowSyntheticDefaultImports 以实现类型系统的兼容性。

当我四处搜索时，我看到两者都设置为 true（至少就我所针对的行为而言）。但是，据我了解文档、TS 和转译为 JS，两者都使用是没有意义的。

按照我的想法，我可能只使用后者并完全删除前者。然而，由于谨慎和谦虚，我并不完全确定并担心我现在正在做一些不那么光明的事情而没有意识到这一点。

我担心这是不恰当的事情，稍后会在驴子上咬我，导致数小时的哀叹和拉扯头发，同时拼命排除故障。怀疑的基础是两个选项都可用，所以我推断有四种情况需要所有组合（true/false 等），但我无法想象它们是哪一种是。

如果 --esModuleInterop: true 在 compilerOptions 中跳过 --allowSyntheticDefaultImports 是否完全安全？如果是这样，为什么我们有这个选项？

额外问题：这两个选项的所有四种组合 (true/false) 何时需要？

【问题讨论】：

标签： javascript typescript webpack-4 typescript3.0

【解决方案1】：

根据此处的相关文档：https://webpack.js.org/guides/typescript/，这两个选项具有不同的意义。根据项目代码和依赖库语法，可能需要一个/两个选项。

【讨论】：

【解决方案2】：

好吧，我的理解是，allowSyntheticDefaultImports 是为了能够以更简单的方式加载 CommonJS 库，如果你以 es6+ 为目标（在开发时间），而esModuleInterop 是为了简化这些导入（在运行时），如果你的目标是例如 AMD（就像我一样）。

根据文档，如果您启用了esModuleInterop，则不需要明确指定allowSyntheticDefaultImports，但我还必须启用allowSyntheticDefaultImports 的原因是Resharper 似乎在执行此操作时会查看该标志Visual Studio 中的语法检查。当然，它只使用esModuleInterop 就可以构建并正常工作，但是我从 Resharper 收到了很多红色警告，直到我还启用了另一个标志。

【讨论】：

【解决方案3】：

如果您的意思是您可以将 allowSyntheticDefaultImports 保留为未定义并仅定义 esModuleInterop，那么答案应该是“是”，但这个问题一直存在。 PR #26866 好像是修复了，9 月 17 日才合并，所以短期内可能会有一些风险。

为什么两者都存在，我相信它们都是解决导入 Babel 转译模块的兼容性问题的一部分，原始 PR 在某些编译时消息中添加了 allowSyntheticDefaultImports 选项，但实际上并没有解决运行时问题进口行为。所以 --esModuleInterop 是后来添加的。有关如何更新文档的讨论，请参阅 TypeScript-Handbook/#816...

【讨论】：