映射與模塊化的遷移指南)
構(gòu)建工具前端【免費(fèi)下載鏈接】brunch Web applications made easy. Since 2011.項(xiàng)目地址https://gitcode.com/gh_mirrors/br/brunch點(diǎn)擊查看免費(fèi)下載本文是 Brunch.io 官方指南見 packages/brunch-guide/content/fr/README.md系列的一部分聚焦如何將 Brunch 接入一個已存在的項(xiàng)目。如果你正從 Grunt、Gulp 或其他構(gòu)建工具遷移而來面對的是一個早已成型的代碼庫而非按 Brunch 約定從零搭建的新項(xiàng)目那么本指南將圍繞五個關(guān)鍵決策點(diǎn)展開源碼在哪里、用什么語言、構(gòu)建產(chǎn)物放哪里、源文件如何映射到目標(biāo)文件、以及是否啟用模塊化包裝。讀完后你將能寫出第一份真正服務(wù)于存量項(xiàng)目的brunch-config并理解paths、conventions、files、modules這些核心配置項(xiàng)在 Brunch 內(nèi)部的真實(shí)運(yùn)作方式。遷移前要回答的五個問題把 Brunch 交給一個既有項(xiàng)目之前先冷靜回答以下五個問題它們分別對應(yīng)brunch-config中的一組具體配置源碼文件在哪里—— 決定paths.watched的值即 Brunch 要構(gòu)建并監(jiān)視的根目錄集合。這些源碼用什么語言編寫—— 決定你需要安裝哪些 Brunch 插件sass-brunch、stylus-brunch、jade-brunch 等。構(gòu)建產(chǎn)物輸出到哪個目錄—— 決定paths.public的值。源文件到目標(biāo)文件的映射關(guān)系是什么—— 決定files配置中javascripts、stylesheets、templates三個小節(jié)的結(jié)構(gòu)與joinTo規(guī)則。要不要把應(yīng)用 JS 包裝成模塊—— 決定modules.wrapper與modules.definition的設(shè)置。下面逐一深入。問題一源碼在哪 ——paths.watched與相關(guān)約定paths.watched用于描述構(gòu)建所依賴的根路徑集合。其默認(rèn)值為[app, test, vendor]見 lib/utils/config-validate.js 中的 schema 定義但絕大多數(shù)存量項(xiàng)目都需要顯式修改它——你的源碼可能分布在src/、lib/或若干個平級目錄中而默認(rèn)的app目錄根本不存在。圍繞源碼位置還有兩個conventions配置需要一并考慮conventions.assets指定哪些目錄下的文件會被原樣復(fù)制copy-paste到輸出目錄而不經(jīng)過任何編譯或打包。默認(rèn)匹配規(guī)則為/assets\//見 lib/utils/config-validate.js也就是說任何路徑中包含assets/的文件都會被當(dāng)作靜態(tài)資源直接搬運(yùn)。conventions.vendor指定哪些目錄中的 JS不應(yīng)被包裝成模塊默認(rèn)匹配規(guī)則為/(^node_modules|vendor)\//見 lib/utils/config-validate.js。需要注意如果通過 Bower 引入組件Brunch 對這些組件永遠(yuǎn)不做模塊包裝即使它們不在vendor目錄中。從實(shí)現(xiàn)上看這兩條約定在配置加載時會被歸一化為可復(fù)用的判定函數(shù)。在 lib/utils/config.js 的normalizeConfig中每個約定都通過anymatch編譯成conventions[key]檢查器其中vendor約定直接使用該檢查器而其他約定則額外排除了 npm 包路徑!deppack.isNpm(path) fn(path)。這些檢查器隨后被 lib/fs_utils/file_list.js 用來決定一個文件被歸入assets靜態(tài)資源還是files源碼并最終決定其是否參與模塊包裝。示例假設(shè)你的存量項(xiàng)目源碼放在src/第三方庫在lib/third_party/// brunch-config.js module.exports { paths: { watched: [src, lib/third_party] }, conventions: { assets: /assets\//, vendor: /third_party\// } };問題二用什么語言 —— 按需混裝插件問題二決定你需要哪些Brunch 插件。核心思想是同一類源碼可以混用多種語言及其插件。例如使用 Bootstrap 時作者傾向于直接用它的 SASS 源碼這樣可以通過修改_variables.scss輕松定制主題而自己的樣式則偏愛 Stylus于是sass-brunch與stylus-brunch常常同時安裝、同時工作。如果應(yīng)用采用客戶端 MVC 架構(gòu)通常會把模板獨(dú)立成文件這時可用jade-brunch或dust-linkedin-brunch之類的模板插件把模板透明地編譯成導(dǎo)出唯一渲染函數(shù)的模塊——該函數(shù)接收一個 presenter即 view model對象作為參數(shù)并同步返回 HTML 字符串。插件混裝之所以可行源于 Brunch 的管道式編譯設(shè)計(jì)。在 lib/fs_utils/pipeline.js 中nextCompiler會按compiler.pattern依次匹配文件路徑并逐個調(diào)用compiler.compile(file)直到?jīng)]有插件能處理為止換言之多個編譯器可以串聯(lián)作用于同一份源碼也可以按路徑各司其職。每種源碼類型如sass、stylus、jade對應(yīng)一個實(shí)現(xiàn)了compile方法、聲明了pattern的插件對象。問題三構(gòu)建產(chǎn)物輸出到哪 ——paths.publicpaths.public指定構(gòu)建產(chǎn)物的輸出目錄默認(rèn)值為public見 lib/utils/config-validate.js。有兩點(diǎn)值得注意該目錄不必在構(gòu)建前存在Brunch 在寫出文件時會自動創(chuàng)建目錄見 lib/fs_utils/generate.js 中writeFile對父目錄的遞歸創(chuàng)建邏輯。所有目標(biāo)文件路徑即joinTo的鍵都是相對于paths.public解析的。從源碼看lib/utils/config.js 中的setConfigDefaults會把paths.public與paths.root拼接成絕對路徑并將其同步到config.server.publicPath保證內(nèi)置服務(wù)器在overrides生效后仍指向正確的輸出目錄見 lib/utils/config.js。問題四源到目標(biāo)的映射 ——files與joinTofiles配置是遷移中最核心、最靈活的部分最多包含三個小節(jié)javascripts所有最終產(chǎn)出為 JS 的文件模板預(yù)編譯除外stylesheets所有最終產(chǎn)出為 CSS 的文件templates所有模板預(yù)編譯產(chǎn)物——每個模板被預(yù)編譯成一個渲染函數(shù)接收 presenterview model對象、返回 HTML通常其目標(biāo)與javascripts的核心目標(biāo)相同。每個小節(jié)至少包含一個joinTo屬性。joinTo的值可以非常簡單也可以相當(dāng)高級形式一單個字符串如果只提供一個文件路徑字符串該小節(jié)所有候選文件都會被拼接到這一個文件中files: { stylesheets: { joinTo: stylesheets/app.css } }形式二對象多目標(biāo) 過濾如果提供一個對象則鍵是目標(biāo)文件路徑值是 anymatch 匹配集用于決定哪些源文件進(jìn)入哪個目標(biāo)。匹配值可以是類型說明示例String精確匹配 Brunch 眼中的文件路徑見下文模塊名從哪來對路徑形態(tài)的說明app/init.js正則表達(dá)式匹配文件路徑特別適合路徑前綴/^app\//、/^vendor\//謂詞函數(shù)接收精確路徑同步返回布爾值決定是否收錄path path.endsWith(.coffee)數(shù)組上述任意類型的混合[app/, /^vendor\//]下面是一個真實(shí)項(xiàng)目Chaplain 骨架的完整示例見 packages/skeletons/brunch-with-chaplin-js/brunch-config.jsexports.config { files: { javascripts: { joinTo: { javascripts/app.js: /^app/, javascripts/vendor.js: /^(?!app)/ } }, stylesheets: { joinTo: stylesheets/app.css }, templates: { joinTo: javascripts/app.js } } };可以看到j(luò)avascripts被拆成app.js以app開頭的文件與vendor.js其余文件兩個目標(biāo)templates與核心 JS 共享同一個目標(biāo)javascripts/app.jsstylesheets則使用最簡單的字符串形式。從源碼看joinTo在配置加載時會被統(tǒng)一歸一化。在 lib/utils/config.js 的normalizeJoinConfig中字符串形式的joinTo會被轉(zhuǎn)換為{[目標(biāo)路徑]: () true}即所有文件都進(jìn)這一個目標(biāo)對象形式則對每個目標(biāo)值調(diào)用anymatch(checker)編譯成匹配函數(shù)。此外lib/utils/config.js 中的createJoinConfig還隱含一條規(guī)則如果javascripts定義了joinTo而templates沒有定義templates會自動繼承javascripts.joinTo——這正是上面示例中模板可以省略、也可以顯式寫出同一個目標(biāo)的底層原因。還有一個補(bǔ)充機(jī)制值得一提config.files.javascripts.entryPoints可以把joinTo視為一種入口點(diǎn)的特殊情形讓某個入口文件單獨(dú)打包見 lib/utils/config.js但入口文件必須位于paths.watched之內(nèi)否則會報(bào)錯。問題五要不要模塊化 ——modules.wrapper與modules.definition第五個問題在作者看來根本不該是問題當(dāng)然要用模塊。默認(rèn)情況下 Brunch 采用CommonJS這既便于編寫同構(gòu) JS也為日后遷移到原生 ES6 模塊鋪路。模塊化由兩個配置聯(lián)合控制默認(rèn)值見 lib/utils/config-validate.jsmodules.wrapper決定單個源文件如何被包裝成模塊默認(rèn)commonjsmodules.definition決定模塊系統(tǒng)的運(yùn)行時定義代碼如何注入輸出文件默認(rèn)commonjs。可用的取值取值效果commonjs默認(rèn)每個模塊被包裝為require.register(模塊名, function(exports, require, module) { ... });并在輸出頭部注入 CommonJS 的 require 定義false關(guān)閉包裝/定義文件內(nèi)容原樣輸出——適合想回到石器時代的純拼接場景amd使用 AMD 模塊包裝自定義函數(shù)為更小眾的模塊系統(tǒng)提供完全定制化的包裝與定義邏輯從源碼看lib/utils/modules.js 中的getWrapperFn明確給出了commonjs與false兩種內(nèi)置包裝器的實(shí)現(xiàn)前者生成require.register(...)的前綴與后綴后者直接返回原數(shù)據(jù)即不包裝。normalizeWrapper還會先對路徑做規(guī)范化再調(diào)用nameCleaner得到最終模塊名lib/utils/modules.js。運(yùn)行時定義則由 lib/utils/modules.js 的normalizeDefinition決定commonjs返回commonjs-require-definition包見 packages/subdependencies/commonjs-require-definition/require.jsfalse則返回空字符串。需要提醒的是模塊包裝只對非 vendor、非 helper的 JS 生效。在 lib/fs_utils/source_file.js 中_shouldBeWrapped要求文件isJS !isVendor換言之命中conventions.vendor的文件即使開啟了 CommonJS 也不會被包裝。模塊名從哪來 —— 默認(rèn)命名算法與nameCleaner使用模塊化后最后一個重要話題是模塊名。默認(rèn)情況下 Brunch 的模塊命名算法分三步取文件相對于監(jiān)視根目錄的精確路徑例如app/application.js去掉擴(kuò)展名得到app/application如果只有一個參與模塊包裝的監(jiān)視路徑默認(rèn)只有app則去掉該前綴得到application但如果存在多個參與包裝的監(jiān)視路徑前綴會保留。如果你不滿意默認(rèn)命名可以通過modules.nameCleaner提供一個自定義的模塊名計(jì)算函數(shù)。默認(rèn)的nameCleaner實(shí)現(xiàn)是path path.replace(/^app\//, )見 lib/utils/config-validate.js與上述第三步的行為完全吻合。實(shí)戰(zhàn)示例保留長文件名、輸出短模塊名假設(shè)你的存量項(xiàng)目把第三方庫放在app/externals/目錄文件名攜帶版本與語言信息如jquery-1.11.2-min.js、moment-2.2.1-fr.js但你希望模塊名保持簡潔通用如jquery、moment。此時可以在brunch-config.js中這樣寫module.exports { modules: { nameCleaner(path) { return path // 去掉 app/ 與 app/externals/ 前綴 .replace(/^app\/(?:externals\/)?/, ) // 去掉形如 -1.11.2 的版本號后綴 .replace(/-\d(?:\.\d)/, ) // 把 -fr. 語言后綴處理成 . .replace(-fr., .) } } };這個函數(shù)的輸入正是從監(jiān)視根目錄開始的相對路徑 擴(kuò)展名它在 lib/utils/config.js 的normalizeConfig中被傳入wrappers.normalizeWrapper并在 lib/utils/modules.js 中應(yīng)用于每一個被包裝的模塊路徑最終出現(xiàn)在require.register(jquery, ...)的模塊名位置上。驗(yàn)證與調(diào)試配置加載路徑一覽理解上述配置如何進(jìn)入運(yùn)行時有助于排查遷移中的問題。在 lib/utils/config.js 的loadConfig中完整流程大致是讀取項(xiàng)目根目錄的package.json按優(yōu)先級加載配置package.json中的brunch字段 →brunch-config.js→ 默認(rèn)配置見tryToLoadlib/utils/config.js用 skemata schema 校驗(yàn)配置并填充默認(rèn)值見 lib/utils/config-validate.js應(yīng)用overrides按NODE_ENV/BRUNCH_ENV等環(huán)境切換例如 test/fixtures/config-with-overrides.js 展示了按環(huán)境切換paths.public的用法對應(yīng)測試見 test/config.js歸一化joinTo與conventions生成config._normalized加載插件并開始構(gòu)建。遷移存量項(xiàng)目時若發(fā)現(xiàn)文件沒有按預(yù)期進(jìn)入某個目標(biāo)優(yōu)先檢查三處paths.watched是否覆蓋了真實(shí)源碼目錄、conventions.vendor是否誤傷了應(yīng)參與包裝的文件、以及joinTo的正則是否與實(shí)際路徑形態(tài)相對監(jiān)視根目錄吻合。小結(jié)將 Brunch 接入存量代碼庫本質(zhì)上就是用一份brunch-config明確回答五個問題源碼位置paths.watched、語言與插件sass-brunch、stylus-brunch、jade-brunch等、輸出目錄paths.public、源到目標(biāo)的映射files.javascripts/files.stylesheets/files.templates及joinTo的字符串、正則、函數(shù)、數(shù)組四種匹配形式、以及模塊化策略modules.wrapper/modules.definition/modules.nameCleaner。這五組配置的組合能力足以讓 Brunch 在不重構(gòu)既有目錄結(jié)構(gòu)的前提下接管任何歷史項(xiàng)目的構(gòu)建而joinTo的 anymatch 匹配與模塊名的自定義清洗則是讓遷移過程既保目錄原貌、又得模塊整潔的兩個關(guān)鍵杠桿?！干弦黄０宄躞w驗(yàn) ? 下一篇開發(fā)與生產(chǎn)構(gòu)建」贊分享構(gòu)建工具前端【免費(fèi)下載鏈接】brunch Web applications made easy. Since 2011.項(xiàng)目地址https://gitcode.com/gh_mirrors/br/brunch點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Terratest v2 導(dǎo)入路徑遷移完全指南import map 全量映射表與源碼級解讀Terratest v2 導(dǎo)入路徑遷移完全指南import map 全量映射表與源碼級解讀 Terratest v2 將原本單一的 github.com/gr測試開發(fā)工具DevOps質(zhì)量保障未來已來ElasticDL與DLRover的技術(shù)演進(jìn)與自動擴(kuò)展訓(xùn)練展望未來已來ElasticDL與DLRover的技術(shù)演進(jìn)與自動擴(kuò)展訓(xùn)練展望 在當(dāng)今AI大模型時代分布式深度學(xué)習(xí)訓(xùn)練已成為技術(shù)發(fā)展的必然趨勢。 ElasticDL大模型人工智能NLP本地部署微調(diào)模型推理服務(wù)notepad-- 代碼折疊3 步把 5000 行文件折成一張目錄notepad 代碼折疊3 步把 5000 行文件折成一張目錄 周一 9:40你盯著一份 4800 行的 .cpp 文件滾輪翻了 20 分鐘回答不出一個桌面應(yīng)用上一篇IDM激活腳本完整使用教程如何永久免費(fèi)使用Internet Download Manager下一篇終極指南Tachyon多項(xiàng)式乘法優(yōu)化中NTT與Karatsuba算法的性能對比創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 在存量代碼庫上使用 Brunch：路徑、語言、目標(biāo)映射與模塊化的遷移指南
構(gòu)建工具前端【免費(fèi)下載鏈接】brunch Web applications made easy. Since 2011.項(xiàng)目地址https://gitcode.com/gh_mirrors/br/brunch點(diǎn)擊查看免費(fèi)下載本文是 Brunch.io 官方指南見 packages/brunch-guide/content/fr/README.md系列的一部分聚焦如何將 Brunch 接入一個已存在的項(xiàng)目。如果你正從 Grunt、Gulp 或其他構(gòu)建工具遷移而來面對的是一個早已成型的代碼庫而非按 Brunch 約定從零搭建的新項(xiàng)目那么本指南將圍繞五個關(guān)鍵決策點(diǎn)展開源碼在哪里、用什么語言、構(gòu)建產(chǎn)物放哪里、源文件如何映射到目標(biāo)文件、以及是否啟用模塊化包裝。讀完后你將能寫出第一份真正服務(wù)于存量項(xiàng)目的brunch-config并理解paths、conventions、files、modules這些核心配置項(xiàng)在 Brunch 內(nèi)部的真實(shí)運(yùn)作方式。遷移前要回答的五個問題把 Brunch 交給一個既有項(xiàng)目之前先冷靜回答以下五個問題它們分別對應(yīng)brunch-config中的一組具體配置源碼文件在哪里—— 決定paths.watched的值即 Brunch 要構(gòu)建并監(jiān)視的根目錄集合。這些源碼用什么語言編寫—— 決定你需要安裝哪些 Brunch 插件sass-brunch、stylus-brunch、jade-brunch 等。構(gòu)建產(chǎn)物輸出到哪個目錄—— 決定paths.public的值。源文件到目標(biāo)文件的映射關(guān)系是什么—— 決定files配置中javascripts、stylesheets、templates三個小節(jié)的結(jié)構(gòu)與joinTo規(guī)則。要不要把應(yīng)用 JS 包裝成模塊—— 決定modules.wrapper與modules.definition的設(shè)置。下面逐一深入。問題一源碼在哪 ——paths.watched與相關(guān)約定paths.watched用于描述構(gòu)建所依賴的根路徑集合。其默認(rèn)值為[app, test, vendor]見 lib/utils/config-validate.js 中的 schema 定義但絕大多數(shù)存量項(xiàng)目都需要顯式修改它——你的源碼可能分布在src/、lib/或若干個平級目錄中而默認(rèn)的app目錄根本不存在。圍繞源碼位置還有兩個conventions配置需要一并考慮conventions.assets指定哪些目錄下的文件會被原樣復(fù)制copy-paste到輸出目錄而不經(jīng)過任何編譯或打包。默認(rèn)匹配規(guī)則為/assets\//見 lib/utils/config-validate.js也就是說任何路徑中包含assets/的文件都會被當(dāng)作靜態(tài)資源直接搬運(yùn)。conventions.vendor指定哪些目錄中的 JS不應(yīng)被包裝成模塊默認(rèn)匹配規(guī)則為/(^node_modules|vendor)\//見 lib/utils/config-validate.js。需要注意如果通過 Bower 引入組件Brunch 對這些組件永遠(yuǎn)不做模塊包裝即使它們不在vendor目錄中。從實(shí)現(xiàn)上看這兩條約定在配置加載時會被歸一化為可復(fù)用的判定函數(shù)。在 lib/utils/config.js 的normalizeConfig中每個約定都通過anymatch編譯成conventions[key]檢查器其中vendor約定直接使用該檢查器而其他約定則額外排除了 npm 包路徑!deppack.isNpm(path) fn(path)。這些檢查器隨后被 lib/fs_utils/file_list.js 用來決定一個文件被歸入assets靜態(tài)資源還是files源碼并最終決定其是否參與模塊包裝。示例假設(shè)你的存量項(xiàng)目源碼放在src/第三方庫在lib/third_party/// brunch-config.js module.exports { paths: { watched: [src, lib/third_party] }, conventions: { assets: /assets\//, vendor: /third_party\// } };問題二用什么語言 —— 按需混裝插件問題二決定你需要哪些Brunch 插件。核心思想是同一類源碼可以混用多種語言及其插件。例如使用 Bootstrap 時作者傾向于直接用它的 SASS 源碼這樣可以通過修改_variables.scss輕松定制主題而自己的樣式則偏愛 Stylus于是sass-brunch與stylus-brunch常常同時安裝、同時工作。如果應(yīng)用采用客戶端 MVC 架構(gòu)通常會把模板獨(dú)立成文件這時可用jade-brunch或dust-linkedin-brunch之類的模板插件把模板透明地編譯成導(dǎo)出唯一渲染函數(shù)的模塊——該函數(shù)接收一個 presenter即 view model對象作為參數(shù)并同步返回 HTML 字符串。插件混裝之所以可行源于 Brunch 的管道式編譯設(shè)計(jì)。在 lib/fs_utils/pipeline.js 中nextCompiler會按compiler.pattern依次匹配文件路徑并逐個調(diào)用compiler.compile(file)直到?jīng)]有插件能處理為止換言之多個編譯器可以串聯(lián)作用于同一份源碼也可以按路徑各司其職。每種源碼類型如sass、stylus、jade對應(yīng)一個實(shí)現(xiàn)了compile方法、聲明了pattern的插件對象。問題三構(gòu)建產(chǎn)物輸出到哪 ——paths.publicpaths.public指定構(gòu)建產(chǎn)物的輸出目錄默認(rèn)值為public見 lib/utils/config-validate.js。有兩點(diǎn)值得注意該目錄不必在構(gòu)建前存在Brunch 在寫出文件時會自動創(chuàng)建目錄見 lib/fs_utils/generate.js 中writeFile對父目錄的遞歸創(chuàng)建邏輯。所有目標(biāo)文件路徑即joinTo的鍵都是相對于paths.public解析的。從源碼看lib/utils/config.js 中的setConfigDefaults會把paths.public與paths.root拼接成絕對路徑并將其同步到config.server.publicPath保證內(nèi)置服務(wù)器在overrides生效后仍指向正確的輸出目錄見 lib/utils/config.js。問題四源到目標(biāo)的映射 ——files與joinTofiles配置是遷移中最核心、最靈活的部分最多包含三個小節(jié)javascripts所有最終產(chǎn)出為 JS 的文件模板預(yù)編譯除外stylesheets所有最終產(chǎn)出為 CSS 的文件templates所有模板預(yù)編譯產(chǎn)物——每個模板被預(yù)編譯成一個渲染函數(shù)接收 presenterview model對象、返回 HTML通常其目標(biāo)與javascripts的核心目標(biāo)相同。每個小節(jié)至少包含一個joinTo屬性。joinTo的值可以非常簡單也可以相當(dāng)高級形式一單個字符串如果只提供一個文件路徑字符串該小節(jié)所有候選文件都會被拼接到這一個文件中files: { stylesheets: { joinTo: stylesheets/app.css } }形式二對象多目標(biāo) 過濾如果提供一個對象則鍵是目標(biāo)文件路徑值是 anymatch 匹配集用于決定哪些源文件進(jìn)入哪個目標(biāo)。匹配值可以是類型說明示例String精確匹配 Brunch 眼中的文件路徑見下文模塊名從哪來對路徑形態(tài)的說明app/init.js正則表達(dá)式匹配文件路徑特別適合路徑前綴/^app\//、/^vendor\//謂詞函數(shù)接收精確路徑同步返回布爾值決定是否收錄path path.endsWith(.coffee)數(shù)組上述任意類型的混合[app/, /^vendor\//]下面是一個真實(shí)項(xiàng)目Chaplain 骨架的完整示例見 packages/skeletons/brunch-with-chaplin-js/brunch-config.jsexports.config { files: { javascripts: { joinTo: { javascripts/app.js: /^app/, javascripts/vendor.js: /^(?!app)/ } }, stylesheets: { joinTo: stylesheets/app.css }, templates: { joinTo: javascripts/app.js } } };可以看到j(luò)avascripts被拆成app.js以app開頭的文件與vendor.js其余文件兩個目標(biāo)templates與核心 JS 共享同一個目標(biāo)javascripts/app.jsstylesheets則使用最簡單的字符串形式。從源碼看joinTo在配置加載時會被統(tǒng)一歸一化。在 lib/utils/config.js 的normalizeJoinConfig中字符串形式的joinTo會被轉(zhuǎn)換為{[目標(biāo)路徑]: () true}即所有文件都進(jìn)這一個目標(biāo)對象形式則對每個目標(biāo)值調(diào)用anymatch(checker)編譯成匹配函數(shù)。此外lib/utils/config.js 中的createJoinConfig還隱含一條規(guī)則如果javascripts定義了joinTo而templates沒有定義templates會自動繼承javascripts.joinTo——這正是上面示例中模板可以省略、也可以顯式寫出同一個目標(biāo)的底層原因。還有一個補(bǔ)充機(jī)制值得一提config.files.javascripts.entryPoints可以把joinTo視為一種入口點(diǎn)的特殊情形讓某個入口文件單獨(dú)打包見 lib/utils/config.js但入口文件必須位于paths.watched之內(nèi)否則會報(bào)錯。問題五要不要模塊化 ——modules.wrapper與modules.definition第五個問題在作者看來根本不該是問題當(dāng)然要用模塊。默認(rèn)情況下 Brunch 采用CommonJS這既便于編寫同構(gòu) JS也為日后遷移到原生 ES6 模塊鋪路。模塊化由兩個配置聯(lián)合控制默認(rèn)值見 lib/utils/config-validate.jsmodules.wrapper決定單個源文件如何被包裝成模塊默認(rèn)commonjsmodules.definition決定模塊系統(tǒng)的運(yùn)行時定義代碼如何注入輸出文件默認(rèn)commonjs。可用的取值取值效果commonjs默認(rèn)每個模塊被包裝為require.register(模塊名, function(exports, require, module) { ... });并在輸出頭部注入 CommonJS 的 require 定義false關(guān)閉包裝/定義文件內(nèi)容原樣輸出——適合想回到石器時代的純拼接場景amd使用 AMD 模塊包裝自定義函數(shù)為更小眾的模塊系統(tǒng)提供完全定制化的包裝與定義邏輯從源碼看lib/utils/modules.js 中的getWrapperFn明確給出了commonjs與false兩種內(nèi)置包裝器的實(shí)現(xiàn)前者生成require.register(...)的前綴與后綴后者直接返回原數(shù)據(jù)即不包裝。normalizeWrapper還會先對路徑做規(guī)范化再調(diào)用nameCleaner得到最終模塊名lib/utils/modules.js。運(yùn)行時定義則由 lib/utils/modules.js 的normalizeDefinition決定commonjs返回commonjs-require-definition包見 packages/subdependencies/commonjs-require-definition/require.jsfalse則返回空字符串。需要提醒的是模塊包裝只對非 vendor、非 helper的 JS 生效。在 lib/fs_utils/source_file.js 中_shouldBeWrapped要求文件isJS !isVendor換言之命中conventions.vendor的文件即使開啟了 CommonJS 也不會被包裝。模塊名從哪來 —— 默認(rèn)命名算法與nameCleaner使用模塊化后最后一個重要話題是模塊名。默認(rèn)情況下 Brunch 的模塊命名算法分三步取文件相對于監(jiān)視根目錄的精確路徑例如app/application.js去掉擴(kuò)展名得到app/application如果只有一個參與模塊包裝的監(jiān)視路徑默認(rèn)只有app則去掉該前綴得到application但如果存在多個參與包裝的監(jiān)視路徑前綴會保留。如果你不滿意默認(rèn)命名可以通過modules.nameCleaner提供一個自定義的模塊名計(jì)算函數(shù)。默認(rèn)的nameCleaner實(shí)現(xiàn)是path path.replace(/^app\//, )見 lib/utils/config-validate.js與上述第三步的行為完全吻合。實(shí)戰(zhàn)示例保留長文件名、輸出短模塊名假設(shè)你的存量項(xiàng)目把第三方庫放在app/externals/目錄文件名攜帶版本與語言信息如jquery-1.11.2-min.js、moment-2.2.1-fr.js但你希望模塊名保持簡潔通用如jquery、moment。此時可以在brunch-config.js中這樣寫module.exports { modules: { nameCleaner(path) { return path // 去掉 app/ 與 app/externals/ 前綴 .replace(/^app\/(?:externals\/)?/, ) // 去掉形如 -1.11.2 的版本號后綴 .replace(/-\d(?:\.\d)/, ) // 把 -fr. 語言后綴處理成 . .replace(-fr., .) } } };這個函數(shù)的輸入正是從監(jiān)視根目錄開始的相對路徑 擴(kuò)展名它在 lib/utils/config.js 的normalizeConfig中被傳入wrappers.normalizeWrapper并在 lib/utils/modules.js 中應(yīng)用于每一個被包裝的模塊路徑最終出現(xiàn)在require.register(jquery, ...)的模塊名位置上。驗(yàn)證與調(diào)試配置加載路徑一覽理解上述配置如何進(jìn)入運(yùn)行時有助于排查遷移中的問題。在 lib/utils/config.js 的loadConfig中完整流程大致是讀取項(xiàng)目根目錄的package.json按優(yōu)先級加載配置package.json中的brunch字段 →brunch-config.js→ 默認(rèn)配置見tryToLoadlib/utils/config.js用 skemata schema 校驗(yàn)配置并填充默認(rèn)值見 lib/utils/config-validate.js應(yīng)用overrides按NODE_ENV/BRUNCH_ENV等環(huán)境切換例如 test/fixtures/config-with-overrides.js 展示了按環(huán)境切換paths.public的用法對應(yīng)測試見 test/config.js歸一化joinTo與conventions生成config._normalized加載插件并開始構(gòu)建。遷移存量項(xiàng)目時若發(fā)現(xiàn)文件沒有按預(yù)期進(jìn)入某個目標(biāo)優(yōu)先檢查三處paths.watched是否覆蓋了真實(shí)源碼目錄、conventions.vendor是否誤傷了應(yīng)參與包裝的文件、以及joinTo的正則是否與實(shí)際路徑形態(tài)相對監(jiān)視根目錄吻合。小結(jié)將 Brunch 接入存量代碼庫本質(zhì)上就是用一份brunch-config明確回答五個問題源碼位置paths.watched、語言與插件sass-brunch、stylus-brunch、jade-brunch等、輸出目錄paths.public、源到目標(biāo)的映射files.javascripts/files.stylesheets/files.templates及joinTo的字符串、正則、函數(shù)、數(shù)組四種匹配形式、以及模塊化策略modules.wrapper/modules.definition/modules.nameCleaner。這五組配置的組合能力足以讓 Brunch 在不重構(gòu)既有目錄結(jié)構(gòu)的前提下接管任何歷史項(xiàng)目的構(gòu)建而joinTo的 anymatch 匹配與模塊名的自定義清洗則是讓遷移過程既保目錄原貌、又得模塊整潔的兩個關(guān)鍵杠桿?！干弦黄０宄躞w驗(yàn) ? 下一篇開發(fā)與生產(chǎn)構(gòu)建」贊分享構(gòu)建工具前端【免費(fèi)下載鏈接】brunch Web applications made easy. Since 2011.項(xiàng)目地址https://gitcode.com/gh_mirrors/br/brunch點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Terratest v2 導(dǎo)入路徑遷移完全指南import map 全量映射表與源碼級解讀Terratest v2 導(dǎo)入路徑遷移完全指南import map 全量映射表與源碼級解讀 Terratest v2 將原本單一的 github.com/gr測試開發(fā)工具DevOps質(zhì)量保障未來已來ElasticDL與DLRover的技術(shù)演進(jìn)與自動擴(kuò)展訓(xùn)練展望未來已來ElasticDL與DLRover的技術(shù)演進(jìn)與自動擴(kuò)展訓(xùn)練展望 在當(dāng)今AI大模型時代分布式深度學(xué)習(xí)訓(xùn)練已成為技術(shù)發(fā)展的必然趨勢。 ElasticDL大模型人工智能NLP本地部署微調(diào)模型推理服務(wù)notepad-- 代碼折疊3 步把 5000 行文件折成一張目錄notepad 代碼折疊3 步把 5000 行文件折成一張目錄 周一 9:40你盯著一份 4800 行的 .cpp 文件滾輪翻了 20 分鐘回答不出一個桌面應(yīng)用上一篇IDM激活腳本完整使用教程如何永久免費(fèi)使用Internet Download Manager下一篇終極指南Tachyon多項(xiàng)式乘法優(yōu)化中NTT與Karatsuba算法的性能對比創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考