包裝許多內部模塊輸出打字稿

我正在尋找在節點內使用打字稿，目前我習慣於通過純粹使用內部模塊的///<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

包裝許多內部模塊輸出打字稿

回答

相關問題