包装许多内部模块输出打字稿
我正在查看在节点内使用打字稿，目前我习惯通过纯粹使用内部模块的///<reference.../>语法来使用打字稿。 但是，对于较大的项目，这可能会变得笨重，因为您可以使用引用其他模块的模块来引用相关链接。
因此，对于这个节点项目，我正在考虑尝试将所有逻辑组件作为内部模块/类进行分组，所以它们将全部在内部互相引用，而通过一个外部模块公开它们，从而暴露底层类等。
这种方式的语法将非常类似现有的需要机制的节点，如：
import database = require("my-external-db-module.ts"); var connection = new database.Connection(someUrl);
而不是
///<reference path="my-internal-db-modules.ts" /> var connection = new Database.Connection(someUrl);
我想象的语法是这样的：
///<reference path="all-my-internal-module-files-etc.ts" /> ///<reference path="..." /> export module SomeExposingModule { // Not quite sure what to put in here to expose the internal modules }
那么，围绕这类事情或其他任何类似的事情有什么最好的做法，或者每个人都坚持使用内部模块来做复杂的事情吗？
我不知道这是否是不好的做法，但这是我如何解决我的问题。
首先再次对问题进行快速总结：
我有多个文件全部逻辑地分组在一个命名空间下，例如Framework那么下面的所有文件都将是Framework.* ，例如Framework.Database或Framework.UnitOfWork 。 然后，这些都是通过tsc --out framework.js ...编译tsc --out framework.js ...所以我把所有这些输出到一个framework.js文件。
现在上面听起来很好，但是它不允许你在使用–out时导出模块，因为它跨越了多个文件，所以为了节点的工作，我需要以某种方式导出模块，所以我基本上附加了一个额外的打字稿文件，这对我来说在汇编：
// exporter.ts module.exports = Framework;
所以提供这个是添加到tsc编译的最后一个文件，你将会得到如下的结果：
// Framework.js var Framework; (function (Framework) { // lots of good stuff })(Framework || (Framework = {})); module.exports = Framework;
所以这将导出内部模块罚款和出口声明将被列入现在包括exporter.ts文件。
所以我不确定这是否是不好的做法，但是这使我能够获得两全其美的好处，一个可重用的模块，它是用命名空间布置的，分布在一个合理的文件结构中，还有一个编译的单个模块，可以是包括通过引用或由nodejs要求。
所以用法如下所示：
var Framework = require("./framework"); var database = new Framework.Database.DbConnection();
有一些想法有助于平滑这些问题。
如果你有很多引用，你可以使用一个引用文件来pipe理它们。 例如：
references.ts
///<reference path="a.ts" /> ///<reference path="b.ts" /> ///<reference path="c.ts" /> ///<reference path="d.ts" />
所有其他文件…
///<reference path="references.ts" />
你现在有一个你的引用的中央列表，这比在每个文件的顶部编织引用列表容易得多。
在您的具体情况下，我会更倾向于使用import语句并获取NodeJS为我加载模块 – 我将使用文件系统对模块进行分组。
你可以做的是将一组TS文件编译成.js + d.ts组合。 例如以下创buildout.js和out.d.ts
tsc a.ts b.ts --out mod.js --declaration
然后（希望）以下将工作：
///<reference path="mod.d.ts"> var mod = require('mod')