cortex對模塊的依賴基於semantic version進行管理，如果熟悉npm的模塊管理方式，大家都瞭解node的模塊是放在node_modules這個目錄下，每個模塊自己的依賴都放在自己目錄下的node_modules裏面，這樣避免了不同模塊之間的共同依賴版本衝突的問題。
而在前端開發中，套嵌的依賴是不可能的，因爲:
1) web開發的載入是異步的，不能像node那樣去在運行時檢測文件上依賴是否存在，遠程檢測模塊是否存在再載入非常耗時。
2) 文件大小限制，相對於磁盤的廉價，http請求和頁面載入重複的js文件的開銷都是非常大的，不可能通過文件套嵌的方式來實現。
所以cortex的模塊管理是基於一個扁平化的結構:
那麼一個模塊怎麼知道他需要載入的第三方模塊是什麼版本呢？比如store.js, 在代碼中使用時都是
require('store.js')
這個信息只能告訴我們依賴什麼模塊，而不知道具體版本。通常的loader，比如requirejs，的做法是對模塊進行管理, 模塊的映射是:
“` store.js =./mod/store.js.1.0.0.js ““
這相當於一個全局變量，所有的store.js都會被固定到某個版本，即使存在第三方依賴不兼容1.0.0的版本.
component和bower也是採用扁平化的方式來儲存模塊，但只有一層目錄。如果在依賴樹中存在這兩個不同版本，不管是否兼容，最終都會只產生一個版本，而這個版本完全取決於依賴申明的層次，順序和在執行install時異步任務執行的順序，可以說，是隨機的。
如果一個模塊A依賴於jquery的一個低版本, 1.8.3, 而另一個模塊B依賴於1.9.1，最終結果在component中是沒法控制，取決於jquery在依賴樹中的位置，導致一個使用[email protected]功能的模塊最終安裝的是[email protected]而出錯。
而這樣的錯誤是只有在代碼執行時纔會被發現的，對於不熟悉的人也很難意識到是某個模塊中依賴問題，需要對component比較熟悉，並且對自己使用的模塊中依賴也瞭解人才能夠很快的發現問題所在。
這樣模塊的開發者和使用者都需要管理代碼的兼容問題，使用者需要對使用的模塊有什麼依賴也有了解，否則他可能會碰到一個很難以發現bug。任何一個不兼容的模塊都會破壞這個生態環境，從而使得開發者不敢使用已有的模塊而重複的造輪子。
而在cortex中, 正確的版本申明能夠使得只有模塊的開發者才需要關心自己的模塊依賴。而使用者完全不用擔心依賴樹上的深層次組件會影響到自己的代碼。 如果在之前的例子中，模塊A的開發者在開發時是依賴着[email protected], 他可以根據semantic version申明爲:
jquery@^1.8.3
模塊B則申明爲:
jquery@^1.9.1
這樣cortex會發現，存在着[email protected]在保證兼容的情況下滿足兩個需求, 最終會載入正確的[email protected]。而模塊A和B的使用者不需要關係A和B到底使用了什麼版本的jquery, 他只要管理好A和B就好，cortex會幫他處理深層次依賴的問題。
由於其他的loader基本上都是基於 “name => js file”的映射來載入js文件，從而在執行環境中無法區分在不同的代碼中name可能代表的含義不同的需求，這也是cortex目前只支持使用neuron作爲loader的原因。
有了版本信息, 如果有兩個模塊依賴了store.js的相同版本，store.js只會載入一份，而不會每個自帶一份。而cortex支持semantic version的range來申明依賴，使得只要兩個版本是兼容的，就不會出現兩份代碼。
而對於不兼容的代碼，用戶也不用擔心功能性失效或者新版本破壞之前的邏輯，即使在一個頁面多層次的引用到一個模塊的不同版本的情況下, 不同的代碼之間也能夠很好的相互兼容。而這樣的穩定性，對於大型項目來是非常重要的。
在對性能要求很高的環境中，可以對於特定代碼進行優化, 希望排除多餘的文件，可以通過命令
cortex ls store.js
會列出在依賴樹上的所有的store.js，可以發現是哪個模塊依賴了古老的版本，從而去升級或者替換依賴。