2017-05-19 25 views
0

當我帶領你完成引發我的問題的過程時,忍受着我。JavaScript類是否可以接受節點模塊?

我工作在一個節點應用CLI和我使用對象使用該模式來封裝我的業務邏輯:

// my-project/lib/widget/myobject.js 

var MyObject = function(x) { 
    this.x = x; 
}; 

MyObject.prototype.getX = function() { 
    return this.x; 
}; 

module.exports = MyObject; 

我還測試這些對象:

// my-project/test/lib/widget/myobject.spec.js 

var MyObject = require('../../../lib/widget/myobject.js'); 

describe('MyObject', function() { 
    ... 
}); 

有一次,我對我選擇的命名和目錄結構感到不滿。在重寫相對路徑時,我發現自己在幾個spec文件中對這些父目錄引用(..)進行了枯燥的計數。我認爲必須有一種更簡單的方法來引用包含這些對象定義的根目錄。

我發現here的建議之一,建議「將特定於應用程序的模塊放入node_modules中」。

現在,據我瞭解模塊,他們是我從npm下載並在我的項目中使用的軟件包。當我打電話給require時,它們包含一個有用的東西庫,其中包含一個導出給我的API。這不是我如何查看專門爲我的應用程序的內部使用而構建的簡單單一用途類。

如果你一直堅持到目前爲止,謝謝!這裏是我的問題:

如何讓我的應用程序的內部更「模塊化」,以便正確遵循Node模塊系統的意圖,同時保持面向對象?

+0

在處理對象的節點中,我通常只是從資產文件夾中存儲和導入它們。這很大程度上取決於偏好,構建工具和部署,這超出了我的專業知識範圍。 node_modules方法或多或少只是一個資產文件夾,您可以在其中導入靜態資產,並且可以正常工作(但我不建議將npm資源與您自己構建的資產混合)。 –

+0

你說得對,它就像是一個靜態的資產文件夾,但它具有作爲Node查找模塊的默認位置的額外好處。這對我來說是平局。我會使用require('myobject')而不是require('../../../ lib/widget/myobject.js')。我的理解正是你剛纔提到的:將公共模塊與私有模塊混合在一起。這就是我的問題。我基本上在問:「我是這麼做的嗎?還是有其他一些會使這些對象更有意義的慣例?」混合感覺真的很爛。 – jkeeler

回答

0

我不知道如何適合這對生產或你打算分發模塊,但在你的主文件,你可以補充一點:

process.env.NODE_PATH = __dirname; 
require('module').Module._initPaths(); 

這將讓你總是需要相對於文件夾模塊包含你的主文件。即如果你有一個文件:

library/some_file.js 

然後tests/some_other_file.js你可能只是做:

require('library/some_file'); 

或者,你可以在你的主文件里加入一種替代方案:

global.__base = __dirname + '/'; 

和那麼在你的其他模塊需要使用:

var MyObject = require(__base + 'my-project/lib/widget/myobject'); 
+0

是的!我也發現了這些解決方案。我立即打折了NODE_PATH解決方案,因爲我提供的鏈接中有一條語句:「node和browserify都支持,但不鼓勵使用$ NODE_PATH。」 – jkeeler

+0

(糾正我,如果我錯了。)我也不認爲這個解決方案與我的測試跑步者。由於spec文件只需要帶有類定義的js文件,所以我不會從main.js獲得路徑。 – jkeeler

相關問題