在Typescript/JavaScript中名称空间有一些客观的负面现象

Question

我在互联网的不同文章中看到很多，并且听到很多名称空间都是古老而邪恶的东西。我听说很多你应该使用带有模块加载器而不是命名空间的模块，但我不明白使用它们有什么客观的好处。我已经阅读了关于命名空间的不同论点，但他们似乎对我并不那么有说服力。我将列出一些参数，你们请尝试用一些真实世界的例子来解释为什么它们是有效的：

• 命名空间创建至少1个全局变量。但那有什么问题？我不在乎是否有一个叫做angular的全局变量。它会造成什么危害？

• 对于模块，消费者决定要为导入的变量命名。命名导入的能力真的给了我什么？有多大可能会有2个变量命名为angular？而在这些少数情况下会出现重复的变量名我们不能仅仅做到这一点（我没有测试过这一点，但它应该在理论工作）：

  var someOtherName = angular; 
  
  var angular = function() { 
  }; 
  

• 模块与模块装载机使捆绑更容易因为他们把脚本按正确的顺序排列。但为什么他们不这样做，当你明确地告诉他们的顺序，通过在每个文件的顶部添加导入？同样，当你在tsconfig.json中使用“outFile”选项将三斜杠引用放在文件的顶部时，Typescript会按照正确的顺序构建JavaScript。这与进口有什么不同？

• 模块装载机提高了性能。这个让我很困惑。假设我使用Typescript或.NET框架的捆绑工具生成了一个巨大的JavaScript文件，性能会不会相同，因为在这两种情况下我们都有1个文件？ SystemJS会根据需要动态加载这些脚本。这个更有意义，但如果我最终得到一个25kb的JavaScript文件，如果按需加载每个kb，我会获得多少性能提升？毕竟，它只有25kb。

• 即使假设模块和模块加载器比绑定到一个文件中并引用它在html中更好，如果我使用模块加载器来构建库，是否意味着使用我的库的任何人都需要安装加载器依赖项太？

在此先感谢您。

Answer 1

现在使用命名空间在JavaScript中被认为是一个坏主意有很多原因。 所有这些原因适用于TypeScript，因为它只是JavaScript的超集。

你自己回答了其中的一些，但可能看不到它们的意义。 我会尽力解决他们的问题。

隐依赖顺序

当您的代码使用通过命名一些库， 隐含地创建你的代码，您使用的库之间的依赖关系。

这意味着您必须自己管理依赖关系，以便正确加载它们， 或者您需要指示编译器/打包程序，以便它们可以正确安排加载顺序。

这意味着您有一个带外位置来管理此信息，并且容易出错。 如果明天你停止使用这个库，该怎么办？你会记得排除它吗？ 让你的工具去完成工作要好得多。

命名空间冲突

这是一个常见的原因使用全局命名空间的人反对。 您可能认为这种情况很少发生，但一个例子是lodash vs underscore。

命名空间版本

这是命名空间冲突的另一种形式。 如果您的代码和其中一个库使用相同的库x，但版本不同（x公开在全局名称空间x中），那么应在全局命名空间x中使用哪个版本？

模块解决了这个问题。 （免责声明：目前TypeScript类型系统不能正确处理多个版本，所以你可能会看到一些问题并需要解决它）。

禁止树摇动

随着ESM，捆绑诸如rollup和webpack可以执行树形晃动。 通过命名空间使用库不会给捆绑器分析您的代码和树形结构 - 摆脱不需要的位的信息。

刚性

当您通过命名空间暴露你的图书馆，图书馆的内部结构暴露，这意味着你不能没有营造出破改变你的消费重构你的代码。

是的，你可以通过小心地创建适配器或别名来避免这种情况，但这会让你的代码更难以维护，并且很可能最终陷入混乱。

安全

这是值得商榷的，但让你的代码在全局命名空间访问意味着你的代码和潜在的一些国家可以通过其他代码容易访问和修改。

我确信还有很多其他原因，但这些是我现在可以想到的。