包装许多内部模块输出打字稿

我正在寻找在节点内使用打字稿，目前我习惯于通过纯粹使用内部模块的///<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 
}

那么，有没有任何形式的身边这样的事情的最佳做法或谁做类似的东西，或者每个人都只是坚持使用任何其他内部模块复杂的东西？

来源

2013-07-18 Grofit

我不知道这是否是不好的做法，但这里是我如何解决我的问题。

首先再次对问题的快速摘要：

我有多个文件的所有命名空间下的逻辑分组，例如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;

因此，这将出口内部模块f因为现在包含exporter.ts文件，因此现在将包含出口声明。

所以我不确定这是否是不好的做法，但这使我能够拥有两全其美的好处，一个可重用的模块，它与命名空间一起布置，分布在一个合理的文件结构中，模块，可以通过引用或通过nodejs需求来包含它们。

所以使用会是什么样子：

你提出

var Framework = require("./framework"); 
var database = new Framework.Database.DbConnection();

来源

2013-07-31 10:27:44 Grofit

就我而言，使用Unix构建脚本，我发现使用以下命令可以更轻松地实现相同的结果： echo'module.exports = Framework;' >> Framework.js –

您可以做的是将一组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')

来源

2013-07-18 10:07:30 basarat

AH有趣的问题，我也产生从我目前的管道中的* .d.ts。因此，如果我只是将它们全部编译为内部模块，那么通过d.ts需要它们，这会给我提供intellisense和编译时间安全性，但是我希望摆脱使用'/// '语法。这个想法会起到一些作用，因为如果我可以将d.ts文件作为导出模块而不是为我的内部模块编写封装器，这看起来更好。 – Grofit

有一些想法，有助于消除其中的一些问题。

如果您有很多参考文献，可以使用参考文件来管理它们。例如：

references.ts

///<reference path="a.ts" /> 
///<reference path="b.ts" /> 
///<reference path="c.ts" /> 
///<reference path="d.ts" />

所有其他文件...

///<reference path="references.ts" />

你现在有你引用的中心名单，这比在编织引用的名单更容易每个文件的顶部。

在您的具体情况下，我会更倾向于使用import语句并获取NodeJS为我加载模块 - 我将使用文件系统对模块进行分组。

来源

2013-07-18 12:17:28 Fenton

我的问题并不在于管理引用，因为在我当前的项目中，我按照您的说法进行操作，并且它可以正常工作*因此，我有一堆散落在项目中的文件，并且使用构建脚本来生成项目级参考查找文件。但是，我用这种方法得到的问题是，如果我有一个数据库项目和一个依赖于数据库的逻辑项目，使用上述方法，我的logic.js编译文件包含数据库ts文件的内容和逻辑ts文件，而我希望使用外部模块来避免这种额外的编译* guff * – Grofit

对不起，以加倍发表评论，但要继续，所以为了避免这种内部'''/ '的雪球效应'包括我希望在这个新项目中采用外部模块，这样logic.js将只包含来自逻辑文件的已编译的js，并且只会引用其他模块，从而创建一种简单类型的运行时依赖关系，而不是编译时间依赖关系。在我与管理打字稿的好人讨论的一个问题中，我提到了上述方法的问题。 https://typescript.codeplex.com/workitem/923我希望避开外部模块所描述的问题 – Grofit

是的，在你的情况下，我会完全承诺按需加载外部模块，因为它依赖于内置的NodeJS功能。 – Fenton

包装许多内部模块输出打字稿

回答

相关问题