关于gulp:Gulp-结构化最佳实践

在 Gulp 的官网文档中，Gulp 的工作都是写在 gulpfile.js 这一个文件中的，如果工作数量不多，这并不会有什么问题，但当工作数量较多时，会造成代码可读性差，难以保护，多人合作时还会容易造成抵触。因而，更好的解决形式是把 Gulp 的代码结构化。

https://github.com/QMUI/qmui_web

这是一个前端框架，次要由一个 SASS 办法合集与内置的工作流形成，其中工作流局部提供了一系列的工作用于解决前端流程，并且因为是可配置的框架，须要读取配置文件，因而尽管原有的 gulpfile.js 的代码并不宏大，但依然须要进行结构化解决，本文将会具体阐明如何进行结构化解决。

次要的思路是把 gulpfile.js 中的工作扩散到独立的文件中编写，而后在 gulpfile.js 中引入这些 task。因而最简便的办法是把每个 task 独自写在独立的文件中，以 task 名命名文件名，在 gulpfile.js 中把这些文件读取进去，例如：

var del = require('del');

gulp.task('clean', '清理多余文件（清理内容在 config.json 中配置）', function() {
    // force: true 即容许 del 管制本目录以外的文件
    del(common.config.cleanFileType, {force: true});
    console.log(common.plugins.util.colors.green('QMUI Clean:') + '清理所有的' + common.config.cleanFileType + '文件');
});

var gulp        = require('gulp'),
    requireDir  = require('require-dir');

// 遍历目录，加载 task 代码
requireDir('./workflow/task', { recurse: true});

gulp.task('default', ['clean']);

这种办法操作起来比较简单，同时根本不须要改变原有的代码，只需对 gulpfile.js 稍作改变即可。但同时也引入了一些问题，例如，文章结尾说过的，像 QMUI 这类须要读取公共配置文件的需要，这里就无奈解决，各个工作中如果须要引入配置表，都须要独自引入，同时像工具办法这类内容也会反复引入，造成节约。因而实际上，clean.js 中也不是像下面的例子那样编写的，而是采纳 module 的形式拆分工作。

为了防止在子工作文件中反复引入全局的配置、插件依赖和工具办法，更好的形式就是把全局配置、工具办法以及子工作都拆分成模块，并利用 require 的形式引入模块。

首先，能够先看一下结构化后的目录构造：

.
├── gulpfile.js
├── package.json
└── workflow
    ├── common.js
    ├── lib.js
    └── task
        ├── clean.js
        ├── compass.js
        ├── include.js
        ├── initProject.js
        ├── merge.js
        ├── readToolMethod.js
        ├── start.js
        ├── version.js
        └── watch.js

接下来以其中几个文件为示例：

// 申明插件以及配置文件的依赖
var plugins     = require('gulp-load-plugins')({
                    rename: {
                      'gulp-file-include': 'include',
                      'gulp-merge-link': 'merge'
                    }
                  }),
    packageInfo = require('../package.json'),
    lib         = require('./lib.js'),
    config      = require('./config.js');;

// 创立 common 对象
var common = {};

common.plugins = plugins;
common.config = config;
common.packageInfo = packageInfo;
common.lib = lib;

module.exports = common;

var del = require('del');

module.exports = function(gulp, common) {gulp.task('clean', '清理多余文件（清理内容在 config.json 中配置）', function() {
    // force: true 即容许 del 管制本目录以外的文件
    del(common.config.cleanFileType, {force: true});
    common.plugins.util.log(common.plugins.util.colors.green('QMUI Clean:') + '清理所有的' + common.config.cleanFileType + '文件');
  });
};

/**
 * gulpfile.js QMUI Web Gulp 工作流
 */
 var gulp = require('gulp-help')(require('gulp'), {
             description: '展现这个帮忙菜单',
             hideDepsMessage: true
           }),
    fs = require('fs'),
    common = require('./workflow/common.js');

// 载入工作
var taskPath = 'workflow/task';

fs.readdirSync(taskPath).filter(function (file) {return file.match(/js$/); // 排除非 JS 文件，如 Vim 临时文件
}).forEach(function (_file) {require('./' + taskPath + '/' + _file)(gulp, common);
});

总结如下：

公共的配置、插件依赖和工具办法应用一个 common 对象关联起来，并且封装成模块
每个子工作封装成模块，并且能够传入 gulp 和 common 两个参数，这样公共的局部能够复用
gulpfile.js 中遍历工作目录，对所有子工作都执行 require，所有子工作都在 gulpfile.js 中胜利注册

至此，一个残缺的结构化 Gulp 就解决好了，Gulp 的目录构造变得清晰很多，这时候无论是减少工具办法，增删子工作，尤其是多人合作时都会不便很多了。

除了以上的次要思路，在实践中一些事项须要留神：

子工作是被 gulpfile.js require 进去的，因而 gulp.src 和 gulp.dest 的绝对目录关系并不需要批改，仍然是以 gulpfile.js 所在目录为基准。但子工作文件中 require 文件是以子工作文件所在目录为基准的，如下面的代码中 common.js 在引入 package.json 是须要在下层目录中进行操作 —— packageInfo = require('../package.json')。
require 当前目录的模块不能省略 ./，否则有效。
须要有我的项目中依赖了多个 gulp 的插件，举荐应用 (gulp-load-plugins)[https://www.npmjs.com/package…] 插件治理多个插件。

关于gulp:Gulp-结构化最佳实践

开始结构化

workflow/task/clean.js

gulpfile.js

Module 模式的结构化

common.js

clean.js

gulpfile.js

注意事项