构建工具前端【免费下载链接】brunch Web applications made easy. Since 2011.项目地址https://gitcode.com/gh_mirrors/br/brunch点击查看免费下载本文以当前仓库 packages/skeletons/simple-coffee-skeleton 为骨架讲解 Brunch 经典 CoffeeScript 项目模板的目录约定、config.coffee配置要点、模块封装与 vendor 加载机制并结合仓库内 Brunch 源码lib/cli.js、lib/fs_utils/generate.js、lib/utils/config.js说明其底层原理。读完本文你将能理解该骨架的每个目录与文件的职责掌握brunch new/brunch build/brunch watch等命令的使用并能在其基础上改造出自己的 CoffeeScript Stylus Handlebars 项目。骨架是什么simple-coffee-skeleton是 Brunch 官方仓库中附带的一个极简项目模板skeleton其 README 开宗明义这是一个基于 Brunch 的简单 CoffeeScript 骨架主要语言为 CoffeeScript、Stylus 与 Handlebars。它演示了 Brunch 最核心的目录约定与默认构建行为是理解 Brunch 工程化理念的最小可运行样例。值得说明的是从当前仓库实际文件列表看该骨架目录中已提交的部分为app/、test/、README.md、config.coffee、package.jsonREADME 目录树中的vendor/Backbone、jQuery 等第三方脚本属于文档描述的目标结构实际创建项目时应自行放入对应文件下文会结合config.coffee的order.before详细说明。快速开始按 README 的指引克隆仓库后执行npm install brunch buildnpm install会安装骨架package.json中声明的 Brunch 插件依赖见 package.json语言类coffee-script-brunchCoffeeScript 编译、javascript-brunch、css-brunch、stylus-brunchStylus 编译、handlebars-brunch模板预编译优化类uglify-js-brunchJS 压缩、clean-css-brunchCSS 压缩测试类devDependenciesmocha1.3.0、expect.js0.1.2package.json还定义了两个常用脚本scripts: { start: brunch watch --server, test: brunch test }即npm start等价于带内置 HTTP 服务器的监听构建npm test运行测试。目录结构全景README 给出的目录树如下为便于阅读已按当前仓库实际文件补齐具体文件config.coffee README.md /app/ /assets/ index.html images/ /lib/ router.coffee view_helper.coffee /models/ collection.coffee model.coffee /styles/ #骨架 README 中提及实际样式中以 views/styles 形式存在 /views/ templates/ home.hbs styles/ application.styl home_view.coffee view.coffee application.coffee initialize.coffee /test/ spec.coffee /vendor/ scripts/ # backbone.js, jquery.js, console-helper.js, underscore.js styles/ # normalize.css, helpers.cssREADME 对各部分的职责定义如下config.coffee应用配置可在此设置要使用的插件 / 语言app/assets图片与静态文件目录内容会被原样复制到构建输出目录app/下其余目录中的文件会被编译位于app/内的 CoffeeScript或 roy 等其他可编译为 JS 的语言以及 JS 文件会自动被包裹进模块闭包从而可以通过require(module/location)加载app/models与app/views存放应用应继承的基类test/功能测试与单元测试vendor/所有第三方代码不会被包裹成模块而是被立即加载即作为全局脚本直接拼接进输出文件。当执行brunch build或brunch watch时以上内容会默认生成public/目录。config.coffee三通道文件配置骨架的核心配置文件是 config.coffee它演示了 Brunch 最经典的files配置写法——将项目文件按javascripts、stylesheets、templates三条通道分别声明扩展名、合并目标与加载顺序exports.config # See docs at http://brunch.readthedocs.org/en/latest/config.html. files: javascripts: defaultExtension: coffee joinTo: javascripts/app.js: /^app/ javascripts/vendor.js: /^vendor/ order: before: [ vendor/scripts/console-helper.js, vendor/scripts/jquery-1.7.2.js, vendor/scripts/underscore-1.3.3.js, vendor/scripts/backbone-0.9.2.js ] stylesheets: defaultExtension: styl joinTo: stylesheets/app.css order: before: [vendor/styles/normalize.css] after: [vendor/styles/helpers.css] templates: defaultExtension: hbs joinTo: javascripts/app.js各配置项的含义与底层处理如下defaultExtension声明该通道的默认源文件扩展名。javascripts为coffeestylesheets为styltemplates为hbs。在 Brunch 的配置归一化逻辑中扩展名会被用于源文件发现与编译插件选择。joinTo合并输出目标。这里使用了两种形态映射形态javascripts/app.js: /^app/把匹配正则/^app/的源文件即app/目录下被编译的模块合并进app.js把匹配/^vendor/的文件合并进vendor.js字符串形态joinTo: stylesheets/app.css所有样式统一输出到一个文件。 在 lib/utils/config.js 中字符串形态会被normalizeJoinConfig归一化为{[joinTo]: () true}即默认全部合并而映射形态则保留每个输出文件对应的正则随后joinTo会被统一转换成entryPoints的等价形式参与构建。order.before/order.after控制合并顺序。vendor脚本按「console-helper → jQuery → Underscore → Backbone」的顺序放在before确保 Backbone 依赖的 jQuery/Underscore 先于它加载normalize.css放在样式最前、helpers.css放在最后。这一顺序最终会体现为 lib/fs_utils/generate.js 中sort(targets, config, joinToValue)对源文件排序的结果再经concat拼接输出。templates.joinTo: javascripts/app.jsHandlebars 模板会被预编译成 JS 模块并合并进app.js这也是HomeView能直接require(./templates/home)的原因。在 config.js 的归一化中若templates未单独声明joinTo会默认继承javascripts.joinTolib/utils/config.js。应用源码逐文件解读骨架的app/目录构成了一条完整的 Backbone CoffeeScript 最小应用链路。启动器与入口app/application.coffee 是应用引导器bootstrapper通过require拉取视图与路由并初始化# The application bootstrapper. Application initialize: - HomeView require views/home_view Router require lib/router homeView new HomeView() router new Router() Object.freeze? this module.exports Application其中require views/home_view与require lib/router正是 README 所述「app 内文件自动包裹进模块、可用require(module/location)加载」的直接体现模块名就是相对app/的路径不含扩展名。app/initialize.coffee 是 DOM-ready 后的启动钩子application require application $ - application.initialize() Backbone.history.start()它在 jQuery ready 回调里执行application.initialize()并启动Backbone.history启用 hash 路由。入口 HTML app/assets/index.html 末尾以scriptrequire(initialize);/script触发这一过程注意其已按配置引入stylesheets/app.css、javascripts/vendor.js与javascripts/app.js——这与joinTo的输出命名完全对应。路由app/lib/router.coffee 继承Backbone.Router将根路由指向home并把渲染后的homeView塞入bodyapplication require application module.exports class Router extends Backbone.Router routes: : home home: - $(body).html application.homeView.render().el视图基类与页面视图app/views/view.coffee 是所有视图的基类定义了统一的渲染流程require lib/view_helper # Base class for all views. module.exports class View extends Backbone.View template: - return getRenderData: - return render: $el.html template getRenderData() afterRender() this afterRender: - returnrender用template getRenderData()把模板与数据结合后写入元素getRenderData/afterRender是供子类覆写的钩子require lib/view_helper用于加载全局 Handlebars 辅助函数app/lib/view_helper.coffee 中预留了「Put your handlebars.js helpers here」的注释。app/views/home_view.coffee 是具体页面视图通过require ./templates/home引用预编译模板View require ./view template require ./templates/home module.exports class HomeView extends View id: home-view template: template模板文件 app/views/templates/home.hbs 是一个纯 HTML 片段含#content容器与几个链接而 app/views/styles/application.styl 通过import nib引入 nib 的跨浏览器 CSS3 mixin并为#home-view定制了居中布局与标题样式——这正是 README 所说 Stylus Handlebars 组合的落点。模型与集合基类app/models/model.coffee 与 app/models/collection.coffee 分别导出继承Backbone.Model/Backbone.Collection的空基类供业务模型继承# Base class for all models. module.exports class Model extends Backbone.Model# Base class for all collections. module.exports class Collection extends Backbone.Collection测试占位test/spec.coffee 是 mocha 测试的起点文件当前只有一行注释「Write your mocha specs here.」配合devDependencies中的mocha与expect.jsnpm test即brunch test即可在构建后运行该目录下的规格。模块封装与 vendor 加载机制源码级印证README 的核心结论有两条app 内的编译文件进入模块系统vendor 内的第三方脚本不打包直接全局加载。这两点在当前仓库的源码中都能找到直接印证输出文件是否带模块定义取决于生成阶段是否为 JS 类型。在 lib/fs_utils/generate.js 中generate()根据目标文件类型javascript/template从归一化配置里取出norm.modules.definition传给concat再写入path指定的输出文件。也就是说app.js会带上commonjs-require-definition提供的require定义见 packages/subdependencies/commonjs-require-definition/require.js而vendor.js同样可以包含定义但其中的脚本本身不被模块包装只是按顺序拼接、立即可用。模块包装方式由 lib/utils/modules.js 的getWrapperFn/normalizeWrapper决定默认commonjswrapper 会把每个模块包成module.exports形式。README 所述「自动包裹在模块闭包中」正对应这一层处理。因此app/initialize.coffee等业务代码以require(initialize)方式被引用Backbone、jQuery 等则在index.html中先于app.js以script srcjavascripts/vendor.js加载并暴露全局变量供模块内代码直接使用。常用命令速查骨架依赖全局或本地的brunch命令。根据 lib/cli.js 的命令定义常用操作如下命令说明相关选项brunch new [path]别名n在指定路径创建新 Brunch 项目-s, --skeleton [name]指定骨架名或 URLbrunch build [path]别名b一次性构建项目-e/--env、-p/--production、-j/--jobs、-c/--config、-d/--debugbrunch watch [path]别名w监听目录变化并增量重建除构建选项外还有-s/--server启动内置服务器、-n/--network允许网络访问、-P/--port指定端口、--stdinbrunch test运行测试配合 mocha见package.json的scripts.testREADME 中的快速开始npm installbrunch build即对应「构建并生成public/」的默认流程开发期则更常用brunch watch --server获得自动重建与本地预览。小结与扩展方向simple-coffee-skeleton虽然体量很小却完整呈现了 Brunch 的三条核心约定约定优于配置app/、test/、vendor/、public/的固定布局配合config.coffee三通道声明即可开工一切皆模块除 vendorapp/内源码自动进入 CommonJS 模块系统靠require(路径/模块)组织依赖第三方库放vendor/原样前置加载插件化编译CoffeeScript、Stylus、Handlebars 等语言通过*-brunch插件接入并在config.coffee中统一配置。若需要更完整含 Chaplin 框架、控制器与 mediator 模式的 CoffeeScript 骨架可参考仓库内同级的 packages/skeletons/brunch-with-chaplin若要使用 JavaScript ES6则可参考 packages/skeletons/simple-js-skeleton 与 packages/skeletons/with-es6。在此基础上替换defaultExtension、调整joinTo与order即可快速改造出符合自己技术栈的 Brunch 项目。赞分享构建工具前端【免费下载链接】brunch Web applications made easy. Since 2011.项目地址https://gitcode.com/gh_mirrors/br/brunch点击查看免费下载相关推荐Brunch init-skeleton 模块演进全解从独立 CLI 到 brunch new 背后的骨架克隆引擎Brunch init skeleton 模块演进全解从独立 CLI 到 brunch new 背后的骨架克隆引擎 本篇技术指南以 Brunch 仓库中 in构建工具前端coffee-script-brunch 插件完全指南为 Brunch 构建流程接入 CoffeeScript 编译coffee script brunch 插件完全指南为 Brunch 构建流程接入 CoffeeScript 编译 导读 本文围绕 Brunch 生态中的官构建工具前端UmiJS 目录约定完全指南从 pages 目录到项目骨架的约定式架构UmiJS 目录约定完全指南从 pages 目录到项目骨架的约定式架构 导读 UmiJS 是一个类 Next.js 的 React 开发框架其核心设计哲学是前端开发工具上一篇fscrawler文件的智能索引者下一篇aREST为Arduino及ESP8266 WiFi芯片实现REST API的简易库创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考