最近半個月，將seajs構建方式從spm-build改為grunt + grunt-cmd-***，踩坑無數，今天終於基本大功告成，在此總結一下：
首先，這個帖子寫得不錯，介紹了為什麼seajs構建這麼麻煩：為什麼seajs構建這麼麻煩
其實最關鍵的乙個問題，就是用grunt-cmd-transport來提取依賴的時候，會將間接依賴也寫入deps，於是會造成大量無效的http請求（404），關鍵的引數有2個，乙個是transport task的paths引數，第二個是concat task的include引數
paths：表示transport時，到**找依賴的模組，如果找到就寫入deps。如果沒有找到則報錯，但是可以用--force引數強制繼續，不會寫入deps
include：表示concat時，合併哪些檔案。有3個可選值，self，relative（預設），all
self基本是沒用的；relative只會合併相對標識的依賴；all會合併所有依賴：標準構建
require("./menu");// 設定include:relative時會合併
require("uiframework/static/package");// 設定include:all時會合併
在src下有n個模組，每個模組都有很多.js，規定以package.js作為此模組的出口。如果外部模組需要依賴該模組，就用：
require("***/static/package");合併後得到的package.js檔案類似這樣：
可以看到，deps陣列裡把間接依賴也全部寫進來了，正常應該只有uiframework/static/package。像紅框裡的這些檔案，在合併後已經不存在了（開發階段才有），但是seajs還是會發起無效的http請求
為了解決這個問題，把concat的include配置為all
這樣會把這些檔案也全部合併進來，倒是不會再發起無效的http請求了，但是這樣有2個問題
1，合併後的package.js檔案超大，而且大量重複。因為每個模組都有package.js（模組出口），其中有大量重複的內容
2，每個模組都有menu.js，**中是：
require("./menu");觀察用spm build合併出來的檔案：
可以看到deps是正確的，只依賴每個外部模組的出口（當然還有模組內部的所有js），這樣就很完美，不會發起無效的http請求，而且也不需要合併多餘的檔案進來
spm-build內部使用的也是grunt-cmd-transport和grunt-cmd-concat，所以沒道理spm-build能構建成功，自己寫grunt就不行。一怒之下看了spm-build的原始碼，發現它配置的include也是relative，而paths配置是錯的
這裡配置的paths我的目錄結構裡根本就沒有，所以等於是沒有配置paths引數，於是在我的gruntfile裡也把paths去掉，執行grunt報錯，使用--force強制繼續，最後就得到了跟spm-build一模一樣的構建結果。區別是spm-build要求是標準目錄結構，而且需要到每個模組下執行一遍；用grunt則可以自定義目錄結構，而且可以一鍵構建
1、paths不要配置，用--force強制執行
2、include配置為relative
3、開發中規定每個模組只有乙個出口，這樣
require("module_name/static/package");4、開發態和部署態的相對目錄結構要保持一致，這是為了滿足seajs的約定（模組id即路徑）
grunt與seajs結合應用
9.seajs構建的問題 01.png和02.jpg 03.png 將 暫存到.build的檔案中，執行任務後，則自動提取出依賴。然後再將這些依賴檔案進行打包或者壓縮處理 11.seajs配置 12.exports與module.exports的異同 exports是module.exports的引...
seajs專案構建的總結
最近連續折騰了將近乙個星期的seajs構建。踩了不少坑，總結了一些經驗，在這裡貼一下 用seajs做模組化開發，經常用到這個函式 require module path file 或者require file 前者是頂級標識，後者是相對標識，總之都是傳遞給require 的引數，表示要載入別的模組 ...
grunt系列啟動grunt專案
啟動grunt project 1 已經存在的grunt project 假設grunt cli已經安裝了，專案裡面已經有package.json和gruntfile，啟動很簡單 npm install grunt 2 乙個新的grunt project 增加兩個檔案到你的專案裡面 你會在這個檔案裡...