摘要：我覺得這方面的原因是當時對和的依賴，導致大家對的興趣不弄，錯過了最佳時機，這個其實跟百度自己的的技術棧有很大關系。這個阮一峰對于前端構建的變化吐槽過，說新的構建工具就是的構建工具。

最近幾年，前端發(fā)展越來越迅速，各種萌新加入了前端這個大家庭，大有趕IOS、超Android的趨勢呀！同時，萌新們提出了各種前端工作問題，除了最基礎的html、css、js三板斧之外，最讓人頭疼的應該是關于環(huán)境的配置問題，所以以環(huán)境作為切入點，開始一系列的前端開發(fā)環(huán)境配置文章。

主要會涉及到打包、構建、編程工具、debug等等前端環(huán)境，以及前后端分離、Nodejs中間層使用伸展面。

以編程工具而言WebStorm、sublime、Atom、VS Code、Brackets等等一大推，這方面我個人是覺得無所謂，蘿卜青菜各有所愛，優(yōu)缺點基本很明顯，就看個人的接受情況了，舉點例子說下吧：

WebStorm 很全面，無論是純前端還是Nodejs，包括git、svn、命令行、格式化工具都有，使用順手之后各種方便，而且還直接支持nodejs的debug，作為前端的全能重量級IDE非常不錯，唯一不好的就是太重，體現(xiàn)在內(nèi)存占有，啟動時間上。

sublime 輕量級文本編輯器，3比較2來說有很大提升，小巧靈活是最大的特點，麻煩的是各種插件的配置，需要自己來組合，不熟悉的人用起來遠遠不想WebStorm方便，快捷。而且每次新的電腦都要配置一次，比較繁瑣。（現(xiàn)在有可以導出配置文件來適用新電腦的方法）

Atom類似sublime，比較輕量級，內(nèi)核主要是Nodejs寫出來的，前端各種愛，因為比較適合前端的技術棧，但是大文件的性能問題一直受人詬病，不是很流暢，還有就是插件比起sublime來說還是少了不少，整個生態(tài)不如sublime，但是因為是github出的，還是受人青睞不少。我貢獻的一個vue格式化插件

VS Code 和 Brackets這兩個比較小眾，使用的很少，我用過VS，感覺還挺不錯，就是生態(tài)更差，而且很多插件的說明寫的很糟糕，讓人看不懂。各方面的資料也比較少。Brackets 一個同事使用過，提示比較好，個人感覺入門很不錯。貌似還能及時瀏覽web效果。

個人建議使用入門的時候使用sublime或者Atom就可以，配置一下自己喜歡的插件，基本就可以開始干活了，當然如果是用eclipse已經(jīng)很習慣的人，我覺得WebStorm這種重型機槍，可能更適合你。不要對工具的提示產(chǎn)生依賴太過于嚴重，否則很多東西自己會慢慢遺忘的哦！！！

PS：如果要提升自己的逼格怎么辦？請使用VIM或者Emacs這種高逼格的編輯方法。

糧草生產(chǎn)的快，也要有好的運輸工具才能上到前線，對于前端而言，屬于我們的運輸工具是打包構建工具。

打包構建工具經(jīng)歷了各種不同的時代，從服務端主宰的打包構建，到現(xiàn)在前端自己主宰的構建工具，不同的需求產(chǎn)生了各種不同的構建工具，這些工具其實也算前端的工作能力之一，因為每一種新的工具都有優(yōu)缺點，熟悉的使用也并非特別簡單的事情。

先來說說都有哪些不同的種類吧：

后端為主要的整體打包工具，這個以FIS作為代表，大家或多或少都應該知道百度出的這個開源打包構建工具鏈，從整體上解決了前端工程的問題，包括優(yōu)化、資源加載、模塊打包、自動化、部署一系列問題，從功能上看非常全面，F(xiàn)IS3的升級讓人也感覺很是不錯，不再依賴PHP和java之類的服務端語言，基于Nodejs來做，更加貼近前端社區(qū)。那么缺點是什么呢： 生態(tài)環(huán)境不夠豐富，主要插件應該還是百度自己人提供的，參與進來的社區(qū)人數(shù)不夠多。我覺得這方面的原因是fis2當時對PHP和JAVA的依賴，導致大家對fis的興趣不弄，錯過了最佳時機，這個其實跟百度自己的web的技術棧有很大關系。同時帶來的好處是，F(xiàn)IS可以結合PHP做整體網(wǎng)站的部署和構建。以上主要是看文檔的一些分析，本人并沒有用過FIS，有說錯請拍磚。這類的打包構建工具還有很多，大部分都是大公司的內(nèi)部使用，例如京東、馬蜂窩之類，都是PHP為主，加上前端的整體構建工具。

Grunt派系，這個應該是比較早的Nodejs打包構建工具，一度很是流行，Grunt的好處是提供了一個核心的構建規(guī)范，基于文件，來使用各種Grunt的插件組合整個構建行為，當時我記得比較清楚的是我前面文章提到過的Yeoman這個構建工具，核心就是Grunt，自動生成了各種插件配置。但是這個有很大的缺點：一是構建的配置文件寫的很長很啰嗦，二是效率不是很高，原因是它構建的方式基于文件的，每次都會產(chǎn)生新的臨時文件，這樣無形中就會有磁盤的I/O讀寫，所以會降低整體的構建速度。

Gulp新體系，因為以上的Grunt的缺點，Gulp應運而生，借鑒了Unix的管道概念，用Nodejs的stream特性，來組織整個構建鏈條，在官方的核心只提供幾個方法，大家基于官方API來編寫自己需要的處理插件，再組合起來，完成構建功能。和Grunt的基本理念很像，但是很多又有區(qū)分，例如：配置和運行分離，插件單一職責，規(guī)定大于配置等等。關于這兩個的比較有很多，大家可以搜搜Grunt Gulp 就知道了。不多說

新的王者Webpack，個人感覺應該是15年上半年到16年初，Webpack橫空出世，大有一舉統(tǒng)一整個前端構建生態(tài)的趨勢，貌似現(xiàn)在FE們不會點Webpack相關的，都不好意思說自己是前端了。最初Webpack應該只是和requirejs、browserify之類模塊化工具比對，但是其靈活的API和豐富的loader，致使它可以連帶完成Gulp之類的構建事件，目前其生態(tài)環(huán)境巨好，各種插件層出不窮，比較火的React，vuejs等都有相關的針對性loader來優(yōu)化構建方式，可以說是目前最流行的工具。不過缺點也特別的明顯，就是難懂，主要是過于靈活，各種方式都能接受，導致沒有一個統(tǒng)一的標準，配置起來特別難受，在群里，一般對于Webpack的配置問題的是最多的。很多新手對于Webpack的各種配置錯誤，感覺都欲哭無淚，想死的心都有了。相關的文章也很多，推薦題葉的入門指南。

逼格提升的NPM構建方式。這個阮一峰對于前端構建的變化吐槽過，說新的構建工具就是ES6的構建工具。推薦看賀師俊的答案如何評價阮一峰關于前端工具變化快的言論？

就我個人而言，目前主要還是使用的Webpack來構建，當然一些比較老的系統(tǒng)代碼，由于歷史原因，還是使用的Gulp來構建，也有正在切換之中的，Gulp+Webpack。比較豐富多彩（其實有點混亂）。

var gulp = require("gulp");
var less = require("gulp-less");
var plugins = require("gulp-load-plugins")();
var pngquant = require("imagemin-pngquant");


gulp.task("default", function(){
    gulp.src("less/zhanzhao.less").pipe(less()).pipe(gulp.dest("css/"));
    gulp.src("less/liuqian.less").pipe(less()).pipe(gulp.dest("css/"));
    gulp.src("less/student.less").pipe(less()).pipe(gulp.dest("css/"));
    return gulp.src("less/company.less").pipe(less()).pipe(gulp.dest("css/"));
});

gulp.task("clean",function(){
    return gulp.src("publish/").pipe(plugins.clean());
});


gulp.task("bulid", ["clean"],function(){
  gulp.src("favicon.ico").pipe(gulp.dest("publish/"));
    gulp.src("download/**/*").pipe(gulp.dest("publish/download/"));
    gulp.src("mail/**/*").pipe(gulp.dest("publish/mail/"));
    gulp.src("statement/**/*").pipe(gulp.dest("publish/statement/"));
    gulp.src("template/**/*").pipe(gulp.dest("publish/template/"));
  gulp.src("css/**/*.css").pipe(plugins.minifyCss()).pipe(gulp.dest("publish/css/"));
    gulp.src("scripts/**/*.js").pipe(plugins.uglify()).pipe(gulp.dest("publish/scripts/"));
  return gulp.src("images/**/*").pipe(plugins.cache(plugins.imagemin({
            optimizationLevel: 5,
            progressive: true,
            svgoPlugins: [{removeViewBox: false}],
            use: [pngquant()]
        }))).pipe(gulp.dest("publish/images/"));
});

gulp.task("revision",["bulid"],function(){
  gulp.src(["template/head-js.html", "template/baidu.html"]).pipe(plugins.concat("head-js.html")).pipe(gulp.dest("publish/template/"));

  return gulp.src(["publish/css/*.css","publish/scripts/config.js","publish/images/**/*"],{base: "publish"})
        .pipe(plugins.rev())
        .pipe(gulp.dest("publish/"))
        .pipe(plugins.rev.manifest({
          merge: true
        }))
        .pipe(gulp.dest("publish/"));
});


gulp.task("publish", ["revision"],function(){
  var manifestCss = gulp.src("publish/rev-manifest.json"),
      manifestDownload = gulp.src("publish/rev-manifest.json"),
      manifest = gulp.src("publish/rev-manifest.json");

  gulp.src("publish/css/*.css")
    .pipe(plugins.revReplace({manifest: manifest}))
    .pipe(gulp.dest("publish/css/"));
 
  gulp.src("*.html")
    .pipe(plugins.revReplace({manifest: manifestCss}))
    .pipe(gulp.dest("publish/"));

  gulp.src("publish/download/*.html")
    .pipe(plugins.revReplace({manifest: manifestDownload}))
    .pipe(gulp.dest("publish/download/"));
});

上面是我曾經(jīng)自己配置的一個打包構建gulpfile，里面做了上述我提到的所有事情，除了js模塊化打包之外，這個大家可以自己研究下，比較簡單。我來解釋下各個任務的作用。

default， 主要是監(jiān)聽less變化生成css。

clean， 清除掉publish文件夾的內(nèi)容

bulid，把源碼移動到publish文件夾下面，對于一些類型的文件做處理，例如css的壓縮，js的壓縮，圖片的壓縮緩存等等。

revision，md5文件，根據(jù)html，css的引用來給相關的文件添加md5戳，生成新的md5戳文件，來保持文件更新。

publish，根據(jù)上面 revision生成的新的md5文件來做一次文件替換，替換里面js，css，image的引用路徑。

其實有些地方可以優(yōu)化的，這個大家有時間可以自己去試試。

以上就是這個系列的第一篇文章，歡迎吐槽和討論各種問題，第二篇文章會以Webpack為主，來解釋它的配置方案。