背景

前端经历了初期的野蛮生长（切图，写简单的特效）——为了兼容浏览器兼容性而出现的各种类库（JQUERY,YUI等——mv*（饱暖思淫欲，代码多了，也就想到怎样组织代码结构，backbone，angularjs等）——工程化（利用grunt，gulp，yeoman做项目脚手架以及打包部署），然而这些东西配置起来需要一定的门槛，并且需要跟业务耦合。全端化、全栈化以及工程化的大环境下，我们希望有这样一套工具可以尽量多的支持业务场景，尽量少的配置，尽量简单的使用命令。而DBL就是这样一个前端自动化工具，主要功能：项目脚手架，本地server（实时监控，修改立即生效）,本地可视化mock数据并会自动化生成接口文档，deploy项目。下面会详细介绍该工具的使用。

安装dbl工具

sudo npm install dbl -g
dbl -V

项目脚手架

mkdir demo && cd demo
dbl init

运行命令后，dbl会为我们初始化项目结构：

|-demo
   |-- src
       |-- index.html
       |-- css
       |-- js
   |-- make-webpack.config.js
   |-- package.json
   |-- aliasMap.json
   ...

如何使用及工具优势

我们的项目脚手架依赖webpack（如果对此不熟悉的可以自行谷歌），优势在于：

• 比起grunt，gulp，在配置上要简单很多。另外，grunt，gulp只是作为打包工具，如果要做模块化开发，还必须引入requirejs或者seajs。而用了dbl，你完全不用考虑那些麻烦的配置问题，一切都帮你配置好了，你可以像写node一样写js了。

• 模块化开发，一个完整模块应该包含html，css，js。在传统工具中，我们很难维护模块css和js保持同步。而dbl，可以用做到在开发过程中直接这样使用：

/**这是文件 component/list.js**/
require('component/list.less')

工具会自动把less编译成css，并且在html页面上生成style标签，并把css插入进去。细心的你可能会说，html应该对于style标签有个数限制，太多无法支持。而且如果上线时采用这种方式不能很好的利用cdn缓存——不过，不用担心，deploy的时候，我们会把这些style提取出来，根据页面级别合并成一个css文件。

• 资源尽量利用浏览器缓存。利用angularjs + requirejs，如果有多个vm页面，公用的资源我们习惯用grunt-requirejs根据页面打包在一起。这样做，就忽视了浏览器缓存对于性能的影响。而dbl，如果有两个页面共同引用了一个模块，这个模块将会被打包到common.js。

• 支持less，sass（这个考虑到很多用户安装时会出问题，如果需要自己在 make-webpack.config.js配置里加上即可）。这种可配置的方式极大的考虑了扩展。

• 本地server。修改自动生效，而且几乎是瞬时的。

• 本地mock数据。mock数据是通过启用另外一个node服务作为数据提供方。

dbl server -p 3001

此命令运行后，mock服务自动启动。默认端口是8001——注意server和mock是两个独立服务。mock服务可以可视化编辑接口，会自动生成接口文档，方便前后端合作。而且只要项目在，理论上这个文档一定是最新的。比记录在doc文档系统方便多了。你可以通过:http://localhost:8001 访问，界面长这样：

• dbl deploy 命令会把资源进行打包压缩，并且在当前目录下生成build文件夹。到这里，你就可以愉快的把此目录上传到cdn上了。