Bower 和 Grunt 配合时，目录结构比命令更重要

Bower 刚流行起来时，很多人最兴奋的是“前端终于也能装依赖了”。但真把它放进项目以后，很快就会碰到另一个更实际的问题：第三方库装到哪里，业务代码放到哪里，Grunt 打包时又该从哪些目录取文件。

不要让第三方库和业务代码混住

如果把 jQuery、Bootstrap、插件脚本和自己写的业务模块都放在一个目录里，最开始看起来省事，时间一长就很难分清哪些文件能改，哪些只是外部依赖。等到升级版本或者查问题时，目录就会像堆在一起的仓库。

我更愿意把项目至少分成三层：

• app 或 src 放业务源码
• bower_components 放第三方依赖
• dist 放最终产物

这类分层不花哨，但能让 Grunt 的拷贝、拼接、压缩任务有很稳定的边界。

打包时要想清楚哪些文件需要被处理

很多早期示例会把所有脚本都过一遍 concat 和 uglify，但第三方库并不一定需要按同样方式处理。有些文件已经是压缩版，有些还带着自己的 source map，再重复加工一次不一定有意义。

比较现实的思路是：业务代码由自己掌控，可以决定检查、拼接和压缩策略；外部依赖则先按“可引用资源”看待，需要时复制到发布目录，或者只挑真正用到的版本。这样一来，构建速度和调试清晰度都会好一些。

目录结构其实决定了后续协作方式

前端项目一旦不只是自己维护，目录含义就会变得很重要。新同事进来第一眼看的不是命令行，而是文件摆放有没有规律。看到 src、vendor、dist 这类层次清楚的结构，马上就能判断修改入口和发布出口。

反过来说，如果目录本身已经含混不清，Grunt 任务再多也只是把混乱自动执行了一遍。

小结

Bower 和 Grunt 在 2013 年是一组很常见的搭配，但真正能把项目带向工程化的，不是“会不会装插件”，而是是否先把目录结构和文件边界想明白。目录一旦清楚，后面的依赖升级、打包配置和多人协作都会顺很多。