用grunt搭建web前端开发环境

1.前言

本文章旨在讲解grunt入门，以及讲解grunt最经常使用的几个插件的使用。

2.安装node.js

Grunt和全部grunt插件都是基于nodejs来运行的，若是你的电脑上没有nodejs，就去安装吧。安装nodejs很是简单，彻底傻瓜式、下一步下一步下一步、的安装方式，这里再也不赘述。去 https://nodejs.org/ 上，点击页面中那个绿色、大大的“install”按钮便可。我这儿在百度云盘存放一个，须要的点击下载

安装了nodejs以后，能够在你的控制台中输入“node -v”来查看nodejs的版本，也顺便试验nodejs是否安装成功。
如图所示：

须要注意的是grunt依赖于nodejs的v0.8.0及以上版本。

3. 安装grunt-CLI

注意，若是你的电脑不联网，如下操做你都作不了，因此，首先保证电脑联网。

“CLI”被翻译为“命令行”。要想使用grunt，首先必须将grunt-cli安装到全局环境中，使用nodejs的“npm install…”进行安装。若是你不了解nodejs的npm如何安装软件，这里就先不要问了，先照着我说的作。
打开控制台（注意：windows系统下请使用管理员权限打开），输入：

注意，mac os 系统、部分linux系统中，在这句话的前面加上“sudo ”指令。

回车，命令行会出现一个转动的小横线，表示正在联网加载。加载的时间看你网速的快慢，不过这个软件比较小，通常加载时间不会很长，稍一下子，就加载完了。你会看到如下界面。

这时候要验证一下grunt-cli是否安装完成并生效，你只须要继续在命令行中输入“grunt”命令便可。若是生效，则会出现如下结果：

4. 建立一个简单的网站

Grunt是应用于实际项目的，因此咱们得有一个简单的测试网站来演示grunt的安装、使用。
首先，我在电脑的E盘下面建了一个“grunt_test”文件夹，里面建了三个空文件夹、两个空文档，名称以下图。（注意 Gruntfile.js 文件的首字母大写！）

其余的东西先不要管，先把package.json这个文件写一些东西。记住，既然文件后缀名叫“json”，那么文件中的格式确定是严格的json格式。

书归正传。Package.json的内容咱们写成以下格式：

{
  "name": "grunt_test",
  "version": "1.0.0",
  "devDependencies": {
  
  }
}

很简单，咱们把这个网站或系统的名称、版本写了一下。可是，不光是写在这里占空的，之后会用到的，具体如何用，咱们下文会有介绍，先别着急。

还有，最后一个“devDependencies”是什么意思？字面意思解释是“开发依赖项”，即咱们如今这个系统，将会依赖于哪些工具来开发。如今代码一行都没有写，依赖于谁？谁也不依赖！因此，就先写一个空对象。可是下文会慢慢把它填充起来。

另外，其实package.json中你能够增长任何符合json格式的代码，它生来自由，仅仅受json代码格式的限制。

怎么样，看到这里，是否是以为下文颇有悬念，很想看下去呀？那就继续！

5. 安装grunt

　　接下来咱们会有一系列插件的安装，他们的安装过程和grunt同样。可是他们的执行都是基于grunt的，所以才能把grunt叫作一个“构建工具”。Grunt没有具体的做用，可是它能把有具体做用的一个一个插件组合起来，造成一个总体效应。

　　例如，你须要检查js语法错误，而后再去压缩js代码。若是这两步你都去手动操做，会耗费不少成本。Grunt就能让你省去这些手动操做的成本。

　　书归正传。注意，这里安装grunt再也不是全局安装了，须要你在控制台进入到网站或系统的具体目录下。这里咱们进入 E:\grunt_test 目录下。

而后输入如下命令：

注意，先不要按回车，先不要执行，先看看下文的描述！

　　这里须要解释的是，“—save-dev”的意思是，在当前目录安装grunt的同时，顺便把grunt保存为这个目录的开发依赖项。看到“开发依赖项”这一次，是否是以为有些眼熟？上文在配置package.json时，其中的“devDependencies”中就会存储开发依赖项。

　　具体保存为开发依赖项是一个什么效果？动手安装一下就是了。首先，在运行安装grunt的命令以前，package.json中的“devDependencies”对应的是空对象。

如今咱们来运行这行命令。你会看到几条warning提示，不用管它。而后接下来就是加载状态，一个旋转的小横线。稍等待一下子，会提示你安装成功。以下图：

如今你应该第一时间打开package.json去看看，那里的“devDependencies”有什么变化。我这里的变化以下图，看看你的是否是和个人同样？

{
  "name": "grunt_test",
  "version": "1.0.0",
  "devDependencies": {
    "grunt": "^0.4.5"
  }
}

而后你再看看文档目录中的文件或者文件夹有什么变化？我这里多了一个“node_modules”文件夹，其中有一个“grunt”文件夹，再其中有若干文档。这里就是存储grunt源文件的地方。

这是见证奇迹的时刻，别着急，奇迹还没完呢。而后你在控制台运行“grunt”命令。若是你获得一个warning提示，那说明grunt已经起做用了。以下图：

通过以上三步，说明grunt已经在这个目录下成功安装。

那么，为什么咱们在刚才执行grunt时候会有Warning提示呢？根据提示，咱们得知的信息是：Task “default” not found ，如何搞定这个问题？——固然是继续往下看啊。

6. 配置Gruntfile.js

顾名思义，Gruntfile.js 这个文件，确定是为了grunt作某种配置的。按照grunt的规定，咱们首先把Gruntfile.js配置成以下格式。

//包装函数
module.exports = function(grunt){
    //任务配置，全部插件的配置信息
    grunt.initConfig({

        //获取package.json的信息
        pkg: grunt.file.readJSON('package.json')

    });
    //告诉grunt当咱们在终端中输入grunt时须要作些什么（注意前后顺序）
    grunt.registerTask('default',[]);
};

在以上代码中，咱们看到了刚才运行grunt命令，warning提示中的“default”字眼。不妨咱们此时再运行一下grunt命令，看看会不会再次出现“warning”、“default”等字眼。

运行结果告诉咱们“Done, without errors”。那就继续往下吧。
另外请注意Gruntfile.js中的一句话：

//获取package.json的信息
pkg: grunt.file.readJSON('package.json')

这句话是在Gruntfile.js中获取package.json中的内容。在上文配置package.json时咱们说过：package.json中的内容不光是用来占位置的，还能够在其余地方获取。这里不是已经获取了package.json内容了吗？至于获取了如何使用，下文会有介绍，仍是继续往下看吧。

7. Grunt插件介绍

进入grunt官网的插件列表页面 http://www.gruntjs.net/plugins ，咱们能看到grunt到目前位置的全部插件。
插件分为两类。第一类是grunt团队贡献的插件，这些插件的名字前面都带有“contrib-”前缀，并且在插件列表中有星号标注。第二类是第三方提供的插件，不带有这两个特征。

和jquery同样，插件那么多，确定不会所有用。grunt官网插件列表的前几个插件中的前几个插件，下载量最多，它们确定是你们都在用的插件。

我们能够把前几名插件的做用简单描述一下，看看你在实际编码过程当中是否须要？其实不用看就知道答案——确定须要——要否则怎么会下载量那么高呢？

• Contrib-jshint——javascript语法错误检查；

• Contrib-watch——实时监控文件变化、调用相应的任务从新执行；

• Contrib-clean——清空文件、文件夹；

• Contrib-uglify——压缩javascript代码

• Contrib-copy——复制文件、文件夹

• Contrib-concat——合并多个文件的代码到一个文件中

• karma——前端自动化测试工具

以上这些插件，本文不会所有讲到。可是随着讲解其中的一部分，我想你就能掌握使用grunt插件的方法。知道方法了，而后你就能够参考官方文档去使用你想要的插件。

grunt集全世界web前端开发的智慧于一身，比你想一想的更增强大，它的插件库能应对你在web前端开发遇到的任何事情。
还等什么，继续往下看。

8. 使用uglify插件（压缩javascript代码）

Uglify插件的功能就是压缩javascript代码。至于javascript代码压缩的必要和意义，这里就不用在赘述了吧？几乎每个javascript类库或者框架，都有一个 **.min.js 压缩版。

问一句，你平时作javascript开发，都用什么工具来压缩代码？我想这个问题会有许多个答案。可是，使用grunt的uglify插件进行压缩，效果绝对不输于任何插件。

要安装一个插件，你首先要进入这个插件在grunt官网的说明文档页面。咱们在grunt官网插件列表页面，找到“contrib-uglify”点击进入。你要看这里面的说明，而后根听说明进行安装。这里咱们只讲重点。

安装uglify插件的方式，和安装grunt是同样的。还记得grunt是怎么安装的吗？

npm install grunt-contrib-uglify --save-dev

 

这里又出现了熟悉的“—save-dev”，具体的做用在上文安装grunt时已经说过了，再也不赘述。运行这句命令。安装完成以后，你会看到package.json中“devDependencies”节点的变化，以及“node_modules”文件夹里的变化。这两点都在安装grunt时已经详细说过。

如今还不能用，还须要在Gruntfile.js 作配置。

不过，先别着急。咱们既然要使用uglify来压缩javascript代码，固然得建立一个js文件来作实验。咱们在现有的“src”文件夹中新建一个“test.js”，并随便写一些代码。显然，咱们没法经过双手和键盘写出压缩后的代码。

(function(window,undefined){
    function add(a,b){
        return a + b;
    }
    add(10,100);
})(window);

测试文件创建好了。咱们接下来就要把这个js文件进行压缩。

固然，要压缩谁？往哪里压缩？这些都须要配置，在Gruntfile.js中配置。分为三步：

第一步，在grunt.initConfig方法中配置 uglify 的配置参数。以下：

uglify的配置代码：

//uglify插件的配置信息
        uglify:{
            options:{
                banner:'/*! <%= pkg.name %> - v<%= pkg.version %> - <%= grunt.template.today("yyyy-mm-dd") %> */'
            },
            build:{
                src:'src/test.js',
                dest:'build/<%=pkg.name%><%pkg.version%>.min.js'
            }
        }

上图中，对uglify的配置有两项。

　　“options”中规定容许生成的压缩文件带banner，即在生成的压缩文件第一行加一句话说明。注意，其中使用到了pkg获取package.json的内容。

　　“build”中配置了源文件和目标文件。即规定了要压缩谁？压缩以后会生成谁？注意，咱们这里将目标文件的文件名经过pkg的name和version来命名。

　　（PS：上文中说过的package.json的内容终于找到了他被应用的地方了。这样的好处是：例如，对文件版本的管理，你只须要在package.json中修改便可，grunt会自动根据最新的版本号生成相应版本的文件。你不用手动去修改文件的文件名。）

　　最后，这里只是对“options”和“build”的基本应用，还有许多中使用方式，能够去官网查阅。

　　第二步，在 grunt.initConfig 方法以后，要让grunt去加载这一个插件。光配置了，不加载上，如何用啊？

代码以下：

grunt.loadNpmTasks('grunt-contrib-uglify');

第三步，在grunt命令执行时，要不要当即执行uglify插件？若是要，就写上，不然不写。我如今是须要的，因此我写上。也有可能不须要，这种状况谁知道呢？

代码以下：

grunt.registerTask('default', ['uglify']);

以上说的这三步已经OK了，接下来咱们去试试。在控制台中运行grunt命令，看获得什么结果。

控制台将输入以下信息：

再去看看，是否生成了一个压缩后的js文件？

果真。根据package.json中的name和version生成了文件名。并且，压缩后的代码的banner也是符合Gruntfile.js中的配置要求的。

以上就是uglify插件的详细安装、配置说明。Javascript使用uglify压缩，css可以使用cssmin插件压缩。安装、配置方法同样的，再也不赘述。

9. 使用jshint插件（检查javascript语法错误）

若是你仅仅写一个几十行js代码作一个小测试，语法错误的检查大可没必要。但我相信看这篇文章的朋友，确定不限于此，你可能天天都须要写一大堆的js代码来完成本身的工做。即便再牛、再仔细的人也会犯一些低级错误，可是jshint不会。所以，你最好的作法就是每时每刻都让jshint来帮助你检查刚刚写过的js代码，有错误当即发现当即处理。这样一来，大家就不必每隔几天都相聚在会议室进行人工代码走查了。及时代码走查，你也不必刻意的关注语法错误。

还有一些js初级入门的朋友，或者已经有多年js经验，却“不思进取”的朋友。你到如今可能都不知道一些js语法归法。例如：你到如今可能都不知道“==”和“===”到底有什么区别，你到如今都不知道在语句块内定义变量的坏处，还有更多更多你不知道的。怎么办？让jshint来帮助你。

接下来介绍jshint的安装和配置。

插件的安装和安装grunt、uglify没有任何差异，这里再也不赘述了。直接执行下面的命令

npm install grunt-contrib-jshint --save-dev

配置jshint和配置uglify同样。在配置uglify时候咱们讲到了三个步骤，这里也是三个步骤。

第一步，在grunt.initConfig方法中配置jshint。

代码以下：

//jshint的插件配置信息
        jshint:{
            build:['Gruntfile.js','src/*.js'],
            options:{
                jshintrc:'.jshintrc' //检测JS代码错误要根据此文件的设置规范进行检测，能够本身修改规则
            }
        }

和uglify的配置同样，分为“options”和“build”两个部分。“build”中描述了jshint要检查哪些js文档的语法。“options”中描述了要经过怎么的规则检查语法，这些规则的描述文件就保存在网站根目录下的一个叫作“.jshintrc”的文件中。所以咱们在网站的根目录下面添加上这个文档，而且填写上文件内容。

代码以下：

{
  "curly": true,
  "eqeqeq": true,
  "immed": true,
  "newcap": true,
  "noarg": true,
  "undef": true,
  "boss": false,
  "eqnull": true,
  "node": true,
  "expr":true,
  "noempty":true,
  "regexp":true,
  "browser":true,
  "devel":true
}

.jshintrc文件中代码的格式也要遵照严格的json语法，不然无效。那里面这些配置是什么意思呢？想详细了解能够去百度搜索“jshint 配置”关键字，你就能知道答案。这里因为篇幅太多，不过多介绍。总之吧，这个.jshint是我经常使用的配置。

第二步，加载插件。和uglify的加载方法同样。注意，这里没有前后顺序。

代码以下：

grunt.loadNpmTasks('grunt-contrib-uglify');
grunt.loadNpmTasks('grunt-contrib-jshint');

第三步，配置grunt命令启动时，要执行的任务，这里注意前后顺序。你是但愿先检查语法呢？仍是先合并呢？——聪明人应该都知道先检查语法比较好，由于语法对，合并了有什么意义？

代码以下：

grunt.registerTask('default', ['jshint','uglify']);

以上三步配置完了以后，咱们能够测试一下这个jshint到底怎么用。这里我故意将当前建立的test.js文件写一个语法错误。

而后咱们执行“grunt”命令，看jshint能给咱们识别出来这两个错误吗？结果以下：

看到没有，jshint很清除的识别出了这两个错误。并且注意到没有，jshint错误以后呢，其后面的uglify就没有再继续执行。这正式咱们想要的结果。

咱们修改完这些错误，在此执行grunt命令，结果没有提示错误，并且jshint和uglify都顺利执行了。

10. 使用csslint插件（检查css语法错误）

检查css文件的语法错误要使用csslint插件，其安装配置方法和jshint几乎如出一辙。只不过csslint依赖于一个叫作“.csslintrc”的文件做为语法检验的规则，个人“.csslintrc”文件以下。其余内容咱们就不在此赘述了。

代码以下：

{
  "adjoining-classes": false,
  "box-sizing": false,
  "box-model": false,
  "compatible-vendor-prefixes": false,
  "floats": false,
  "font-sizes": false,
  "gradients": false,
  "important": false,
  "known-properties": false,
  "outline-none": false,
  "qualified-headings": false,
  "regex-selectors": false,
  "shorthand": false,
  "text-indent": false,
  "unique-headings": false,
  "universal-selector": false,
  "unqualified-attributes": false
}

11. 使用watch插件（真正实现自动化）

你能够一直有一个疑问，上面将的插件中，每次执行插件功能，都得执行一遍“grunt”命令，这样的操做很是繁琐，说好的“自动化”呢？别着急，接下来就解决这个问题——经过watch插件解决这个问题。

首先安装watch插件，若是安装再也不赘述了。接下来要配置watch插件，配置分为三个步骤，再也不详细描述了，只贴图说明。

第一步。配置watch将监控哪些文件的变化，以及这些文件一旦变化，要当即执行哪些插件功能。以下图，watch将监控src文件夹下全部js文件和css文件的变化，一旦变化，则当即执行jshint和uglify两个插件功能。

第二步，直接帖代码：

grunt.loadNpmTasks('grunt-contrib-watch');

第三步，直接帖代码：

grunt.registerTask('default', ['jshint','uglify','watch']);

这三步执行完了，即watch插件配置完成。运行grunt命令，控制台提示watch已经开始监听。此时要想中止，按ctrl + c便可。

 

既然在监听，咱们试一试看监听有没有效。咱们将 test.js 代码中去掉一个分号，看它可否自动检查出来这个错误。

结果显示，watch检查到了test.js文件的变化，并且经过执行jshint提示了语法错误。更重要的是，它如今还在监听、并未中止。说明它正在等着你去修改错误，从新监听检查。那咱们就不要辜负它了，再把语法错误修复了。看它会如何处理。

它又检测到了文件变化，此次语法没有错误，它很顺利的执行了jshint和uglify，执行完毕以后从新进行监听。多听话的工具！

好了，已经回答了大家的问题——自动化。

12. 上文中所谓的“build”

上文中描述各个插件的配置时，都是用了“build”这一名称做为一个配置项。

那么这里是否是必须用“build”这一个名字？答案很明显，固然不是。我以前之因此没直接说，是由于我要先把插件的安装和配置讲明白，不变一次传输太多知识，如今一并和你们说了。

　　这里能够用任何字符串代替“build”（但要符合js语法规则）。甚至，你能够把“build”指向的内容分开来写。这样对多人协同开发很友好。好的设计就是这样：让用户尽情发挥他们的自由来干事，而不是去限制他们。

如上图，我对jshint的配置作了修改，你们能够去本身修改，而后执行grunt命令试试。命令行会有“test1”、“test2”的字眼。
如图所示：

13. 批量安装插件

请各位看官继续跟随我思考问题，学而不思则罔。

　　到如今为止，我刚刚安装了3个插件，“node_modules”文件夹所占据的空间就有18MB了。你们猜一猜，我在上传代码到开发库的时候，会不会把“node_modules”中的内容也上传呢？既然我这么问了，答案确定是不上传。

　　问题又来了，我若是做为开发环境的搭建者，我不把“node_modules”上传，其余一块儿开发的人，怎么获得这些grunt插件和工具呢？有人回答让他们本身去手动一个一个安装——首先这是一个笨方法，其次若是我当年安装的旧版本，而他们如今本身安装的多是新版本。新旧有可能不兼容啊。

　　该怎么办？

　　其实答案很简单——我上传源码时候，确定会把package.json上传上去，而package.json中的“devDependencies”就记录了这个系统的开发依赖项，而后我经过nodejs的npm便可批量安装。

　　作一个试验。我在E盘下面新建一个目录“grunt_test_1”，而后把“grunt_test”中的package.json拷过去。在打开命令行跳转到“grunt_test_1”，执行“npm install”命令，看看获得什么结果。

此时按回车执行命令，结果在“grunt_test_1”生成了“node_modules”文件夹，里面安装好了package.json中“devDependencies”配置的插件。并且，版本都是一直的。

14. 系统文件结构

　使用grunt来搭建web前端开发环境时候，文档目录和以前可能就不同了。由于你手动写的代码文件，绝对不是你最终输出的文件。这些还须要通过grunt各类插件的检验、合并、压缩才能最终输出给用户。

下面截图看一个文档结构例子：

上图中，“src”文件夹里面存储的是原始的代码文件，“dist”文件夹里面存储的是最终生成的代码文件，“demo”里面存储的是一些测试页面。

固然了，各个系统的文件组织形式不同，可是我建议你们仍是按照这么一个思想去组织文档结构。你们也能够去github上参考一下jquery、bootstrap这些著名开源项目的文档结构。看看jquery输出的虽然是简单的一个js文件，可是它的开发环境是多么的复杂。

参考地址：grunt插件官网：http://www.gruntjs.net/plugins30分钟学会使用grunt打包前端代码:http://www.cnblogs.com/yexiaochai/p/3603389.htmlhttp://blog.csdn.net/wangfupeng1988/article/details/46418203/http://www.xgllseo.com/?p=4287