我有一个相当大的应用程序(~650个文件），它目前混合了ES6模块和遗留的全局名称空间、内部模块和类的实现。
我想转移到100%的ES6模块。
为此，我需要通过添加“export”关键字将所有全局对象转换为ES6模块。
当我添加“export”时，该全局对象就不再是全局的，并且使用该对象的每个文件现在都有一个编译器错误“object not Found”（即无法读取未定义的属性“xxx”）。
为了解决这个问题，必须在文件中添加一个“导入”，从而将其变成一个ES6模块，这反过来又“去全球化”该文件中的所有对象，从而在其他文件中导致新的“对象找不到”错误。
简而言之，这种迭代方法似乎不会很好地工作。
export。import{list,of,symbols,exported,by,the,brare,file}从“./globalbrare”添加到每个文件正如@jfriend000所说：
使用非模块化代码并试图以编程方式将其转换为模块只会造成混乱。
但是把所有的东西都一次放入模块中会使真正的模块化过程变得更容易。
这是最好的方法吗？有什么建议吗？
这是最好的方法吗？有什么建议吗？
我怀疑这甚至不是一个好办法，当然不是最好的办法。
使用非模块化代码并试图以编程方式将其转换为模块只会造成混乱。我相信这是可以做到的，但它并没有真正的收获。这只会让事情变得比以前更糟。您将会把一个非模块化的体系结构变成一堆非模块化的、高度交叉依赖的模块。您的体系结构将不会得到改进，代码将变得更加复杂，而不是变得更复杂。
更好的方法是逐步重新设计功能领域，使之真正“模块化”。为一个功能区域创建一个接口，将其打包到一个模块中，然后转换该功能的所有用户来导入该接口并使用它。这实际上是可以做到的，一次一个功能区域。你不必一下子把整件事打碎，然后再试着把它全部重新组合起来。
摆脱共享全局需要重新思考设计。仅仅将一堆共享全局打包到一个模块中，现在让每个人都导入，并不能真正改善设计--事实上，它甚至可能使情况变得更糟。代码就像以前一样相互交织、相互依赖。
您可以增量地进行这种模块化的重新设计，一次只对代码的一个功能区域进行重新设计，而不是一下子创建一个巨大的混乱局面，实际上并没有改进您的代码的体系结构。
如果我要解决这个问题，我可能会创建一个程序中所有主要功能点的顶层图，并确保650个文件中的每一个都在图的某个地方表示。然后，我开始逐步地挑选出最容易模块化的部分（具有最干净的接口和最少的意大利面依赖关系的部分）。当你把越来越多的东西放到模块中时，剩下的部分开始变得不那么复杂了。如果真的可以访问交织在整个代码中的全局，那么您就必须重新考虑设计的部分，要么创建包含数据的对象并传递这些数据，要么将全局数据移到相关模块中，并为这些数据提供导出的访问器。
