以前我可以这样做:
import foo = require('foo');
但现在 TypeScript (1.5) 支持 es6 模块语法，在 ES6 模块语法中实现相同功能的正确方法是什么。
最佳答案
正确的方法是继续使用旧的导入语法。新的导入语法仅适用于 ES 模块，旧的导入语法适用于 ES6 之前的模块。两者是有区别的，故意如此。 import * as foo from 'foo' 导入模块 'foo' 的所有属性，它不导入默认值 as foo。
From the designer of the feature :
- 导出默认声明总是声明一个名为 default 的导出成员，并且总是作为对 exports.default 的赋值发出。换句话说，
export default始终具有 ES 模块语义。为了与 Babel 兼容，我们可以选择在模块具有默认导出时发出一个__esModule标记，但实际上我们不会将该标记用于任何事情。 - 一个
export =声明，它用一个不同的实体代替模块本身来导出，总是作为对module.exports的分配发出。在使用export =的模块中进行其他导出是错误的。这是现有的 TypeScript 行为。 - 使用
export =导出另一个模块(内部或外部模块)的模块可以使用新的 ES6 结构导入。特别是，方便的解构导入可以与此类模块一起使用。使用export =导出另一个模块的模式在提供内部模块(例如 angular.d.ts)的 CommonJS/AMD View 的 .d.ts 文件中很常见。 - 使用
export =导出非模块实体代替模块本身的模块必须使用现有的import x = require("foo") 导入语法与今天的情况相同。
2016 年更新:TypeScript 编译器在某个时候开始允许import * as foo from 'legacy-module-foo' 来获取遗留模块的默认导入某些情况下。 这违反了 ES6 规范(§15.2.1.16，“值“*”表示导入请求是针对目标模块的 namespace object。”)。
当您以这种方式导入的遗留模块更新为 ES6 模块时，这些模块的“默认”导入将停止工作(因为 * as foo 导入是应该导入命名空间对象)，如果您不知道这样做是对 TypeScript/SystemJS 的 hack，这可能会非常困惑。 future TypeScript 与 ES 规范的重新调整也可能导致它们中断。
因此，您可能更愿意继续使用上述遗留导入语法来加载遗留模块，以避免您自己和其他处理您的代码的开发人员对 ES6 命名空间导入的工作方式感到困惑，并避免混淆破坏性更改。
关于javascript - 用于导入 commonjs/amd 模块的新 es6 语法，即 `import foo = require(' foo')`，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29596714/