构建工具前端【免费下载链接】brunch Web applications made easy. Since 2011.项目地址https://gitcode.com/gh_mirrors/br/brunch点击查看免费下载css-brunch 是 Brunch 官方插件体系中负责处理原生W3CCSS 文件的编译器插件让工程中的.css文件能够进入 Brunch 的编译管线并最终合并输出到目标样式文件。本文以仓库中 packages/addons/css-brunch/CHANGELOG.md 为时间主线完整梳理该插件自 2012 年初次发布到 2.x 时代的每一次版本迭代并结合当前仓库内的源码、配置与测试深入讲解其插件 API 形态、CSS Modules 的实现机制、安装用法以及废弃后的迁移路线帮助读者既掌握插件的使用实操也理解 Brunch 插件体系的底层协作方式。插件定位为 Brunch 添加 CSS 编译能力Brunch 是一个前端构建工具其插件机制的设计非常简洁插件只是一个在prototype上声明了brunchPlugin true的构造函数安装到package.json并存在于node_modules中即被自动加载无需像 Grunt/Gulp 那样显式注册任务。css-brunch 正是按照这一约定实现的样式编译器插件。从 packages/addons/css-brunch/index.js 可以看到当前实现的全部声明信息CSSCompiler.prototype.brunchPlugin true; CSSCompiler.prototype.type stylesheet; CSSCompiler.prototype.extension css;这三个属性决定了插件在 Brunch 中的注册方式brunchPlugin标记该模块是 Brunch 插件会被 lib/utils/plugins.js 中的加载逻辑识别type: stylesheet声明输出文件类型产物会被归入样式目标如public/stylesheets/app.cssextension: css声明它负责编译.css后缀的文件。加载阶段Brunch 会实例化插件构造函数并把全局配置传入new Plugin(config)随后经 lib/utils/plugin-adapter.js 做标准化将compile方法按参数个数统一为接收file对象并返回 Promise 的现代接口同时包裹超时告警与字符串结果转换。编译管线 lib/fs_utils/pipeline.js 则依据compiler.pattern.test(file.path)判断某个文件是否命中某编译插件命中后调用其compile(file)并将返回的data、map、dependencies等字段合并进新的文件对象继续流转——这就是 css-brunch 中每一个 CSS 文件的实际处理路径。说明当前仓库中的 css-brunch 版本为 2.10.0见 packages/addons/css-brunch/package.json而 CHANGELOG 最后记录的正式版本号停留在 2.0.0后续变更以“未发布unreleased”条目累积。版本演进全览CHANGELOG 完整时间线CHANGELOG 是本文的主体骨架它记录了插件从诞生到功能成熟的全过程。以下按时间倒序完整列出全部版本条目版本发布日期核心变更unreleased未发布—新增对 CSS Modules 的支持2.0.02016-01-29重写源码与 API插件仅支持 Brunch 2.2 及以上版本1.7.02013-09-09利用新的插件 API 提升内存效率1.6.02013-06-22改进安装流程1.5.12013-03-19增加 Node 0.10 支持移除 coffee-script 依赖1.5.02013-01-13改进安装过程1.3.02012-06-29增加 Node.js 0.8 / 0.9 支持发布前预编译包1.1.12012-04-15修复安装包时的错误报告1.1.02012-04-09增加 Windows 支持1.0.02012-03-14初次发布从这条时间线可以清晰看出插件的成熟轨迹2012 年初期完成跨平台与多 Node 版本适配2013 年围绕安装体验与内存效率打磨2016 年则随 Brunch 2.x 的插件体系一起完成了一次 API 层面的重写并最终为 CSS Modules 铺路。每一次迭代都不是孤立的功能堆叠而是 Brunch 生态整体演进的一个缩影。2.0.0跟随 Brunch 2.2 的插件 API 重写CHANGELOG 中 2.0.0 条目写道“更新了源码与 API插件现在只与 Brunch 2.2 及以上版本协同工作。”这背后是 Brunch 2.x 对插件接口的全面升级编译器插件不再处理(data, path)字符串对而是统一接收包含data、path、map等属性的file对象并返回 Promise。当前 packages/addons/css-brunch/index.js 中的CSSCompiler正是这一代 API 的标准形态class CSSCompiler { constructor(cfg) { if (cfg null) cfg {}; this.config cfg.plugins cfg.plugins.css || {}; this.modules !!(this.config.modules || this.config.cssModules); } compile(params) { if (this.modules) { const moduleOptions this.modules true ? {} : this.modules; return cssModulify(params.path, params.data, params.map, moduleOptions); } else { return Promise.resolve(params); } } }几个关键点构造函数接收全局配置cfg.plugins.css即用户在brunch-config.js的plugins键下为 css-brunch 预留的配置段这一点与 packages/brunch-guide/content/en/chapter11-plugins.md 中“每个插件通常在plugins键下以插件名作为子键读取自己的配置”的约定完全一致。返回 Promisecompile无论走哪条分支都返回 Promise符合 Brunch 2.x 编译器的异步契约未开启 modules 时直接Promise.resolve(params)原样透传把 CSS 内容完整交给管线中的下一个编译器如 minifier。内存效率的来源相比旧式“复制字符串、逐文件搬运”的实现新 API 让文件对象在编译链路上原地流转、按需替换data字段这正是 1.7.0 以来“利用新插件 API 提升内存效率”的延续与定型。CSS Modules未发布版本的核心能力CHANGELOG 顶部唯一一条“未发布unreleased”记录是“为 Brunch 增加 CSS Modules 支持。”这是 css-brunch 2.x 时代最重要的新特性源码实现集中在 packages/addons/css-brunch/index.js 的cssModulify函数中const cssModulify (path, data, map, options) { let json {}; const getJSON (_, _json) json _json; return postcss([postcssModules(Object.assign({}, {getJSON}, options))]) .process(data, {from: path, map}).then(x { const exports module.exports JSON.stringify(json) ;; return { data: x.css, map: x.map, exports }; }); };它的工作方式可以拆解为三步用postcss加载postcss-modules处理器把原始 CSS 中.title这样的类名改写为带哈希的局部作用域类名通过getJSON回调把“原类名 → 混淆后类名”的映射收集为 JSON 对象将映射序列化为module.exports {...}形式的exports字段返回Brunch 会把这个字符串作为该 CSS 文件的模块导出从而让 JS 代码能够require(./title.css)拿到样式表导出的类名映射。值得注意的是Object.assign({}, {getJSON}, options)意味着用户在配置中传入的options会覆盖默认的getJSON行为因此所有 postcss-modules 支持的选项都能原样透传——例如自定义作用域名生成规则。开启 CSS Modules 的配置方式按 packages/addons/css-brunch/README.md 的说明在brunch-config.js中开启该能力有两种写法。第一种简单开启使用 postcss-modules 默认行为module.exports { // ... plugins: { css: { modules: true } } };第二种将配置对象直接透传给 postcss-modules例如自定义generateScopedName来生成形如[name]__[local]___[hash:base64:5]的作用域类名module.exports { // ... plugins: { css: { modules: { generateScopedName: [name]__[local]___[hash:base64:5] } } } };在源码层面构造函数通过!!(this.config.modules || this.config.cssModules)读取开关因此modules: true与cssModules: true两种写法均可识别compile中再用this.modules true ? {} : this.modules区分“默认参数”与“显式配置对象”。在 JS 中引用 CSS 类名开启 CSS Modules 后样式文件依然按普通 CSS 编写.title { font-size: 32px; }在 JavaScript 中通过 require 引入该样式模块并像使用普通对象一样访问被混淆后的类名var style require(./title.css); h1 className{style.title}Yo/h1全有或全无CSS Modules 的全局生效边界README 特别强调了一个容易被忽视的约束开启cssModules会对项目中的每一个样式表生效属于“全有或全无all-or-nothing”模式。即使某些 CSS 文件从未被require它们同样会被当作 CSS Modules 处理类名会被混淆为类似._title_fdphn_1的形式。因此在启用前需要确认项目中没有依赖原始类名选择器例如由第三方 CSS 框架提供、通过字符串拼接使用的类名否则会出现样式失配问题。安装与使用两种安装路径通过 npm 安装在项目根目录执行npm install --save-dev css-brunch--save-dev保证插件进入package.json的devDependenciesBrunch 启动时会扫描node_modules中名称包含brunch的模块并自动加载。手动安装也可以直接在package.json中写入依赖后执行npm install{ devDependencies: { css-brunch: x.y.z } }这里 README 给出了一条实用的版本匹配经验插件版本号应与 Brunch 的次要版本y保持对应即 Brunch 2.x 搭配 css-brunch 2.x避免因插件 API 契约不一致导致编译异常。若希望使用插件的 git 版本则可写成css-brunch: gitssh://gitgithub.com:brunch/css-brunch.git。运行时依赖当前 packages/addons/css-brunch/package.json 声明的运行时依赖是postcss ~5.1.2与postcss-modules ~0.5.0测试与代码检查则使用mocha、chai、eslint测试脚本为eslint index.js mocha——这说明使用 CSS Modules 能力需要工程能正常安装这两个 npm 依赖。测试验证编译正确性的可执行证据packages/addons/css-brunch/test.js 用 mocha chai 编写了三个核心断言直观展示了插件对外承诺的行为it(should be an object, function() { expect(plugin).to.be.ok; }); it(should has #compile method, function() { expect(plugin.compile).to.be.an.instanceof(Function); }); it(should compile and produce valid result, function(done) { var content #id {color: #6b0;}; var expected #id {color: #6b0;}; plugin.compile({data: content, path: file.css}).then(result { var data result.data; expect(data).to.equal(expected); done(); }, error expect(error).not.to.be.ok); });第三个测试尤其说明问题在未开启 CSS Modules的默认路径下compile返回的data与输入内容逐字节一致即插件作为编译器应保持 CSS 的“透传”语义任何格式化、压缩等变换都应交给后续优化器如clean-css-brunch完成而不是由 css-brunch 擅自处理。早期版本的工程化细节从安装体验到跨平台CHANGELOG 中 2.0.0 之前的一系列条目看似琐碎但组合起来恰好勾勒出早期 Node 工具链生态的演进1.3.0Node 0.8 / 0.9 支持与发布前预编译当时的插件多以 CoffeeScript 编写因此在发布到 npm 之前先编译为 JavaScript既保证兼容性也免去使用方安装 coffee-script 的开销配合 1.5.1 的“移除 coffee-script 依赖”说明插件本体从 CoffeeScript 迁移到了纯 JavaScript。1.1.0Windows 支持与 1.1.1安装错误报告修复对应 Node 工具在 Windows 平台上路径处理与错误反馈逐步完善的时期对当时的国内开发者而言跨平台可用性直接决定了 CI 与本地开发的一致性。1.5.0 / 1.6.0安装过程改进反复打磨安装体验体现了“安装即用、零配置”的 Brunch 插件哲学——正如 packages/brunch-guide/content/en/chapter11-plugins.md 所述插件默认在无任何配置时也应开箱可用。1.7.0新插件 API 提升内存效率是 2.0.0 全面重写的前奏让编译过程从重复拷贝数据改为引用传递为大型项目的构建内存占用控制打下基础。废弃状态与迁移建议css-brunch 的归宿README 开头用醒目方式标注了该插件的现状自 Brunch 2.10 起Brunch 已内置对 CSS 的自动处理能力css-brunch 被官方标记为废弃deprecated建议从package.json中移除若需要使用 CSS Modules则应迁移到postcss-brunch。这一点在核心代码中也有直接证据lib/utils/plugins.js 维护了一个ignoredPlugins列表const ignoredPlugins [ javascript-brunch, css-brunch, ];即当前版本的 Brunch 加载插件时会显式跳过css-brunch与javascript-brunch同理内置实现已接管 CSS 编译职责。因此在 Brunch 2.10 的工程中样式编译无需任何插件即可工作旧的 css-brunch 依赖可以安全移除CSS Modules 需求建议迁移到 packages/addons/postcss-brunch/index.js它在compile中同样支持config.modulestrue或配置对象并额外提供processors、pattern、ignore、map等更丰富的可配置项能够在编译后阶段执行自定义的 PostCSS 处理器与优化器。对于仍然运行在 Brunch 2.2 2.9 且需要原生 CSS 编译的历史工程理解本文梳理的插件契约brunchPlugin/type/extension/compile与版本匹配原则仍能帮助排查“插件不生效”“编译结果异常”等典型问题——这份 CHANGELOG 记录的不只是插件自身的历史更是 Brunch 插件 API 从 1.x 走向 2.x 的缩影。赞分享构建工具前端【免费下载链接】brunch Web applications made easy. Since 2011.项目地址https://gitcode.com/gh_mirrors/br/brunch点击查看免费下载相关推荐Gatsby 内置 CSS 支持完全指南全局 CSS、CSS Modules 与底层构建原理Gatsby 内置 CSS 支持完全指南全局 CSS、CSS Modules 与底层构建原理 Gatsby 对 CSS 的支持开箱即用你无需任何额外配置即可文档教程技术博客如何快速部署HC社区管理系统开发与生产环境安装指南如何快速部署HC社区管理系统开发与生产环境安装指南 HC社区管理系统是一款开源的物业管理SaaS软件提供业主管理、费用收缴、报修处理等核心功能支持Spri后端微服务企业应用MinecraftDev插件终极指南如何在IntelliJ中快速搭建Mod开发环境MinecraftDev插件终极指南如何在IntelliJ中快速搭建Mod开发环境 MinecraftDev是一款专为IntelliJ IDEA打造的插件旨上一篇剑指 Offer 题目分类全览LeetCode-Book 中的算法与数据结构知识图谱下一篇Rerun Color 组件深度解析sRGB 空间 RGBA 颜色的编码、序列化与多语言 SDK 使用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考