TypeScript版本： 3.7.x-dev.20191203
搜索词：
代码
export default {}
const Object = {};预期行为：
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
{
exports.default = {};
const Object = {};
}无错误
实际行为：
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.default = {};
const Object = {};VM69:2 Uncaught ReferenceError: Cannot access 'Object' before initialization
at eval (eval at <anonymous> (main-3.js:1239), <anonymous>:2:1)
at main-3.js:1239** playground链接：**http://www.typescriptlang.org/play/index.html?module=1#code/KYDwDg9gTgLgBAE2AMwIYFcA28DeBfAKAGMIA7AZ3gHkAjAK2CPgF458BuIA
相关问题：
7条答案
按热度按时间u91tlkcl1#
我非常确定
babel做了同样的事情。如果你不兼容地捣乱了Object,那么你也会不兼容地捣乱Object。atmip9wb2#
避免引用全局变量，如
const { Object } = globalThis;,是一种有效的性能调优技术：https://falsandtru.github.io/benchmark/suites/10/但当前的行为阻止了这种调优。
vcirk6k63#
如果你不兼容地捣乱对象，那么你也不兼容地捣乱对象。
顺便说一下，我不确定为什么你写了同样的东西两次。你需要咖啡吗？
8i9zcol24#
在检测到emit无法工作时，我们至少应该发出一个错误。
mftmpeh85#
然而，开发者可能会觉得这个错误很奇怪。而且这个错误只能在少数模块类型(其他依赖于模块类型的类似错误？)下启用。基本上，其他(主要是本地的)模块类型没有这个限制。因此，这是模块类型与一个非常常见的命名空间的不兼容性。编译器应该尽可能地隐藏这种不兼容性。我找不到避免简单解决方案的理由，即只需用花括号包围代码。
gijlo24d6#
Node.js也是这种技术的使用者。
$x_{1e0f1}^{x}$
nxagd54h7#
请注意，您不能使
import { Object } from '...'出错，因为它不会是一个运行时错误。