我正在寻找在节点中使用typescript,我目前习惯使用纯文本使用内部模块的///<reference.../>
语法来使用typescript。但是对于较大的项目,这可能会变得难以处理,因为您可以使用引用其他模块的模块,这些模块都具有相互链接的参考。
因此,对于这个节点项目,我正在考虑尝试将所有逻辑组件组合为内部模块/类,就像之前一样,因此它们将在内部相互引用,但通过一个外部模块公开它们这将暴露基础类等。
这种方式的语法与现有需要机制的节点非常相似,如:
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
}
那么有什么样的最佳实践可以解决这类问题,或者其他任何做过类似事情的人,或者每个人都坚持使用内部模块来处理复杂的事情?
答案 0 :(得分:5)
我不确定这是不是坏习惯,但这是我解决问题的方法。
首先再次快速总结一下问题:
我有多个文件在逻辑上分组在命名空间下,例如Framework
,那里的所有文件都是Framework.*
,例如Framework.Database
或Framework.UnitOfWork
。然后这些都是通过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 require包含它。
所以用法如下:
var Framework = require("./framework");
var database = new Framework.Database.DbConnection();
答案 1 :(得分:2)
有一些想法有助于解决其中的一些问题。
如果您有很多引用,可以使用参考文件来管理它们。例如:
references.ts
///<reference path="a.ts" />
///<reference path="b.ts" />
///<reference path="c.ts" />
///<reference path="d.ts" />
所有其他文件......
///<reference path="references.ts" />
现在您有一个参考的中央列表,这比在每个文件顶部编织参考列表容易得多。
在您的具体情况下,我更倾向于使用import
语句并让NodeJS为我加载模块 - 我会使用文件系统对模块进行分组。
答案 2 :(得分:1)
您可以做的是将一组TS文件编译为.js + d.ts组合。例如以下内容创建out.js
和out.d.ts
tsc a.ts b.ts --out mod.js --declaration
然后(希望)以下内容将起作用:
///<reference path="mod.d.ts">
var mod = require('mod')