摘要：應用層打包工具一開始學其實有點逼不得已，作為一個奉行保守主義的人，對于新東西都會有一種觀望的心態，這不是重點，我不會告訴你其實是因為我懶，真的是因為在簡單的項目上已經足夠好用。

一開始學webpack其實有點逼不得已，作為一個奉行保守主義的人，對于新東西都會有一種觀望的心態，這不是重點，我不會告訴你其實是因為我懶，真的是因為Gulp在簡單的項目上已經足夠好用。

Gulp本身只是一個框架，通過安裝各種插件，可以實現從監聽-打包-合并-壓縮-編譯一系列流程，管道的概念在使用的過程中跟它的前身Grunt比起來簡直舒服太多。（其實我也沒怎么用過grunt……真的不是我懶，是因為出生太晚，我開始接觸這類工具時Gulp已經流行起來了）

然而，在開始實踐組件化開發之后，發現一個有點邪乎的事情：gulp很難處理較為復雜的依賴關系，各組件之間相互引入，寫配置文件時會寫得萬念俱灰。經常哭得把我家狗狗嚇出房間……

即便是一個最簡單的項目，也需要做出如下的路徑配置：

并且，React、Vue、Angular2，這三大MVVM框架都將webpack作為官方推薦的打包工具，雖然還是有點懷念Gulp，但不得不追隨神的指引——去跳Webpack的坑。

webpack最早只是作為一個打包工具出現，也就是只操作js代碼，但由于它智能尋找依賴的特點，很快插件數量就直追而上，就功能而言，現在基本能夠完全取代Gulp，加上基于Express框架開發的webpack-dev-server，讓它有了比Gulp家的browser-sync更贊的熱模塊替換功能，browser-sync在監聽到代碼修改后會重載代碼并刷新頁面，而Webpack的熱模塊替換可以做到在不刷新頁面的情況下替換代碼。

你沒有聽錯，是在不刷新頁面的情況下替換代碼。

上面說的Webpack可以智能查找依賴，是指：無論有多少個組件導入，它會自己尋找到對應的組件并打包在一起，不需要使用者操心。

如果是Gulp，則需要像上面那樣配置一大串路徑并且挨個注入監聽才行。（怎么注入監聽，下面會有例子）

Gulp最得意的莫過于管道式的工作方式，但webpack輕而易舉地就做到了，并且書寫起來更簡潔明了，例如一個最普通的sass打包函數，gulp首先要導入sass編譯模塊，配置好輸入路徑和輸出路徑，還需要將這個函數注入到監聽的服務里：

var sass = require("sass");

gulp.task("sass", function() {
    return gulp.src("./src/*.scss")
        .pipe(sass())
        .pipe(gulp.dest("dist/"));
});

其實這很清晰明了，但有個前提，就是你需要知道哪些CSS是你的應用真正用到的，如果項目龐大，那就不得不硬著頭皮去維護一個無聊的依賴文件列表，或是干脆包含一整個目錄的文件。

舉個栗子說清楚一些：假設你在開發時需要用到一張圖片，如果開發完成后你忘記把這張圖片從開發目錄中刪除，那恭喜你，即便這張圖片沒有被任何代碼引用，也照樣會成功打包進入到生產環境中。

這樣一來，很有可能引入一些冗余的代碼或者一些靜態文件，而且只能寄托命運讓你在某一天醍醐灌頂突然發現這張圖片并沒有被引用。

造成這種隱患的原因是：Gulp是根據路徑打包的，不管這個文件有沒有用到，只要它的位置在Gulp的處理序列內，它就會處理！而Webpack的巧妙在于，被用到的它才打包，沒用到的則是視而不見！這就是按需打包的概念。

此外，還有一處事關體驗的地方，Gulp一旦檢測到報錯信息，就會退出，也就是你寫css代碼的時候多打了個分號，盡管眼睛看見了，然而身體的反射神經遲鈍，手不聽使喚按了保存，世界就毀滅了！你只能嘆息一聲，乖乖把分號刪掉，然后回到終端（控制臺）重啟Gulp服務。

猜猜是誰已經做過無數次這種事……

而Webpack會顯示報錯信息，但是不會宕機，等你修正了錯誤之后，它會重新編譯。有追求的工具就應該這樣?。?！

上面列出了Gulp處理sass的代碼量，相對來說，webpack就簡單多了：

{
  test: /.scss$/,
  use: "style!css!sass"
}

// 不過這么寫的話，css最終會被打包到js文件里，如果想將css多帶帶打包出來，還需要安裝插件，最終寫成下面這樣

const ExtractTextPlugin = require("extract-text-webpack-plugin");

module.exports = {
    module: {
        ...
        rules: [
            {
                test: /.scss$/,
                use: ExtractTextPlugin.extract({
                    fallbackLoader: "style-loader",
                    loader: "css-loader!sass-loader"
                })
            }
        ]
    },
    plugins: [
        new ExtractTextPlugin("./[name].css")
    ]
};

悲催，這好像比Gulp的代碼量更多……

不?。∫陨峡吹降亩际潜砻娆F象！！

不信來份真的比較一下！

var gulp        = require("gulp");
var browserSync = require("browser-sync").create();
var sass        = require("gulp-sass");
var prefix      = require("gulp-autoprefixer");
var cssmin      = require("gulp-clean-css");
var htmlmin     = require("gulp-htmlmin");
var imagemin    = require("gulp-imagemin");
var jsmin       = require("gulp-uglify");
var rename      = require("gulp-rename");
var reload      = browserSync.reload;

var Asset = {       // 配置監聽路徑
    html: "./src/html/*.html",
    js: "./src/js/*.js",
    sass: "./src/sass/*.scss",
    img: "./src/images/*"
}

// 啟動靜態服務器
gulp.task("server", function() {
    browserSync.init({
        server: "."
    });
});

gulp.task("html", function() {      // html代碼的處理模塊
  gulp.src(Asset.html)
    .pipe(htmlmin({collapseWhitespace: true}))
    .pipe(gulp.dest("dist/"));
});

gulp.task("img", function() {       // 圖片的處理模塊，負責壓縮圖片什么的
    return gulp.src(Asset.img)
        .pipe(imagemin({optimizationLevel: 7}))
        .pipe(gulp.dest("dist/images/"));
});

gulp.task("js", function() {        // js的處理模塊
  return gulp.src(Asset.js)
    .pipe(jsmin())
    .pipe(rename({suffix: ".min"}))
    .pipe(gulp.dest("dist/"));
});

gulp.task("sass", function() {      // sass處理模塊
    return gulp.src(Asset.sass)
        .pipe(sass())
        .pipe(prefix())
        .pipe(rename({suffix: ".min"}))
        .pipe(cssmin())
        .pipe(gulp.dest("dist/"))
        .pipe(reload({stream: true}));
});
gulp.task("watch", function() {     // 監聽服務
    gulp.watch(Asset.sass, ["sass"], reload);
    gulp.watch(Asset.js, ["js"], reload);
    gulp.watch(Asset.html, ["html"], reload);
    gulp.watch(Asset.img, ["img"], reload);
    gulp.watch("*").on("change", reload);
    gulp.watch("./dist/**/*.*").on("change", reload);
});

// 啟動
gulp.task("default", ["sass", "img", "html", "js", "server", "watch"]);

那些中括號里面的東東就是注入

這里說的注入跟Angular的依賴注入概念基本一樣！注入這個概念理解起來可能比較困難，換一個詞，應該叫反轉，概念是這樣的：一般的函數形參個數都……

呃……不跑題哈~

const path = require("path");
const ExtractTextPlugin = require("extract-text-webpack-plugin");
const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
    context: __dirname + "/src",
    entry: {
        index: "./js/index.js"
    },
    output: {
        filename: "[name].bundle.js",
        path: __dirname + "/dist"
    },
    module: {
        rules: [
            {
                test: /.scss$/,
                use: ExtractTextPlugin.extract({
                    fallbackLoader: "style-loader",
                    loader: "css-loader!sass-loader"
                })
            },

            {
        　　　　　　test: /.html$/,
        　　　　　　use: "html-withimg-loader"
            },
            {
        　　　　　　test: /.(png|jpg)$/,
        　　　　　　use: "url-loader?limit=8192&name=images/[name].[ext]"
            }
        ]
    },
    plugins: [
        new ExtractTextPlugin("./[name].css"),
        new HtmlWebpackPlugin({
            template: "./html/index.html",
            filename: "./index.html",
            chunks: ["index"]
        })
    ]
};

以上兩份配置文件完成的是差不多的工作，代碼量……

呃……其實也就是半斤八兩，別天真了，成熟一點：少寫幾行代碼并不能體現出什么優越性……

那么從這里開始，態度要轉彎了……

上面說了，文件較多的時候，配置Gulp的各種路徑會萬念俱灰，那么……配置Webpack的時候會比萬念俱灰更加萬念俱灰，跟webpack相比，Gulp倒是顯得挺傻瓜。其實，單純比較代碼量的話，Webpack配置文件的代碼量確實是少些，然而Webpack太過于博大精深，要理解它需要付出不少努力。

學了Webpack是不是就能召喚神龍？

No！！經由Webpack打包出來的代碼可讀性很差，盡管很少人會閑著沒事去讀打包后的代碼，但前端近幾年迭代太快，有人詬病就會有人創新，號稱下一代打包工具的Rollup已經在崛起，它進一步升級了“按需打包”的概念，只是各類插件尚不成熟，因此就目前來看，將Webpack用作應用層的打包還是最合適的。

等我跳了Rollup的坑再來跟各位介紹~