为什么我不必将`import` `anti:fake` 导入我的Meteor 源文件？答案

【问题标题】：Why don't I have to `import` `anti:fake` into my Meteor source files?为什么我不必将`import` `anti:fake` 导入我的Meteor 源文件？
【发布时间】：2017-01-28 23:10:48
【问题描述】：

我已经看到了一些与此类似的问题，但似乎没有一个适用于我的案例。

我正在创建一个 Meteor 项目并使用 Atmosphere 包“anti:fake”来生成测试数据。

对于任何其他包，我必须import 它。即使是 Meteor 本身，我也必须这样做 import {Meteor} from 'meteor/meteor';。对于其他类似的 Atmosphere 包，例如publish-counts，我还必须写一行import {Counts} from 'meteor/tmeasday:publish-counts';。 ...此外，即使我想导入 anti:fake 我也看不到任何导入名称可以正常工作。它们在packages 文件中以相同的方式列出，并以相同的方式添加到我的项目中，因此从表面上看，它们看起来都一样。

这些都不重要，因为我可以神奇地使用一个名为 Fake 的对象，但我真的不明白为什么会这样，以及我将来如何知道我需要显式导入什么以及什么只是隐式导入。

谢谢！

【问题讨论】：

标签： javascript meteor typescript import atmosphere.js

【解决方案1】：

Meteor 1.3 引入了 ES2015 模块，但为了保持向后兼容性，Meteor 仍然保留为您导入 anti:fake 包的“急切加载”行为，将其绑定到全局变量 Fake。

import {Meteor} from 'meteor/meteor' 出于同样的原因实际上并不是必需的，但强烈建议将其作为最佳实践（如果未来的版本通过删除急切加载而放弃了这种向后兼容性，则可能会变得有必要）。

如果您寻找针对 Meteor 1.3 或更高版本的更新教程，您会看到大部分代码都放在 /imports 目录中，因为 Meteor 构建工具处理的方式不同，并且其中的所有代码都不是急切地加载'。此目录中的所有代码都必须显式导入，这与模块命名空间和避免旧的文件加载顺序问题一起，让您更清楚地了解应用程序中正在运行的代码（不那么神奇！）。

Meteor 1.3 中还包含对 NPM 包的支持，它们为您提供了使用大气包的替代方案，并且以这种方式包含的包也需要显式导入到您的应用程序中。

您可以考虑使用https://www.npmjs.com/package/faker。

但是，如果某些东西对你有用，你不必改变，但希望这能帮助你理解它为什么有效！

您确定publish-counts 需要导入语句吗？查看此包的 package.js 会显示这两行

  api.export('Counts');
  api.export('publishCount', 'server');

这使得publishCount 对象在导入此包的应用程序（或包）中的服务器上可用，并且Counts 对象在客户端和服务器上都可用。不需要 import 语句（因为它们被放置在全局命名空间中）

有关详细信息，请参阅Migrating to Meteor 1.3 文档

【讨论】：