如何打造一個使人愉悅的前端開發環境（一）

文章來源

最近幾年，前端發展愈來愈迅速，各類萌新加入了前端這個你們庭，大有趕IOS、超Android的趨勢呀！同時，萌新們提出了各類前端工做問題，除了最基礎的html、css、js三板斧以外，最讓人頭疼的應該是關於環境的配置問題，因此以環境做爲切入點，開始一系列的前端開發環境配置文章。

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

工欲善其事必先利其器

以編程工具而言WebStorm、sublime、Atom、VS Code、Brackets等等一大推，這方面我我的是以爲無所謂，蘿蔔青菜各有所愛，優缺點基本很明顯，就看我的的接受狀況了，舉點例子說下吧：

• WebStorm 很全面，不管是純前端仍是Nodejs，包括git、svn、命令行、格式化工具都有，使用順手以後各類方便，並且還直接支持nodejs的debug，做爲前端的全能重量級IDE很是不錯，惟一很差的就是過重，體如今內存佔有，啓動時間上。

• sublime 輕量級文本編輯器，3比較2來講有很大提高，小巧靈活是最大的特色，麻煩的是各類插件的配置，須要本身來組合，不熟悉的人用起來遠遠不想WebStorm方便，快捷。並且每次新的電腦都要配置一次，比較繁瑣。（如今有能夠導出配置文件來適用新電腦的方法）

• Atom相似sublime，比較輕量級，內核主要是Nodejs寫出來的，前端各類愛，由於比較適合前端的技術棧，可是大文件的性能問題一直受人詬病，不是很流暢，還有就是插件比起sublime來講仍是少了很多，整個生態不如sublime，可是由於是github出的，仍是受人青睞很多。我貢獻的一個vue格式化插件

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

我的建議使用入門的時候使用sublime或者Atom就能夠，配置一下本身喜歡的插件，基本就能夠開始幹活了，固然若是是用eclipse已經很習慣的人，我以爲WebStorm這種重型機槍，可能更適合你。不要對工具的提示產生依賴太過於嚴重，不然不少東西本身會慢慢遺忘的哦！！！

PS：若是要提高本身的逼格怎麼辦？請使用VIM或者Emacs這種高逼格的編輯方法。

木牛流馬

糧草生產的快，也要有好的運輸工具才能上到前線，對於前端而言，屬於咱們的運輸工具是打包構建工具。

打包構建工具經歷了各類不一樣的時代，從服務端主宰的打包構建，到如今前端本身主宰的構建工具，不一樣的需求產生了各類不一樣的構建工具，這些工具其實也算前端的工做能力之一，由於每一種新的工具都有優缺點，熟悉的使用也並不是特別簡單的事情。

先來講說都有哪些不一樣的種類吧：

• 後端爲主要的總體打包工具，這個以FIS做爲表明，你們或多或少都應該知道百度出的這個開源打包構建工具鏈，從總體上解決了前端工程的問題，包括優化、資源加載、模塊打包、自動化、部署一系列問題，從功能上看很是全面，FIS3的升級讓人也感受非常不錯，再也不依賴PHP和java之類的服務端語言，基於Nodejs來作，更加貼近前端社區。那麼缺點是什麼呢： 生態環境不夠豐富，主要插件應該仍是百度本身人提供的，參與進來的社區人數不夠多。我以爲這方面的緣由是fis2當時對PHP和JAVA的依賴，致使你們對fis的興趣不弄，錯過了最佳時機，這個其實跟百度本身的web的技術棧有很大關係。同時帶來的好處是，FIS能夠結合PHP作總體網站的部署和構建。以上主要是看文檔的一些分析，本人並無用過FIS，有說錯請拍磚。這類的打包構建工具還有不少，大部分都是大公司的內部使用，例如京東、馬蜂窩之類，都是PHP爲主，加上前端的總體構建工具。

• Grunt派系，這個應該是比較早的Nodejs打包構建工具，一度非常流行，Grunt的好處是提供了一個核心的構建規範，基於文件，來使用各類Grunt的插件組合整個構建行爲，當時我記得比較清楚的是我前面文章提到過的Yeoman這個構建工具，核心就是Grunt，自動生成了各類插件配置。可是這個有很大的缺點：一是構建的配置文件寫的很長很囉嗦，二是效率不是很高，緣由是它構建的方式基於文件的，每次都會產生新的臨時文件，這樣無形中就會有磁盤的I/O讀寫，因此會下降總體的構建速度。

• Gulp新體系，由於以上的Grunt的缺點，Gulp應運而生，借鑑了Unix的管道概念，用Nodejs的stream特性，來組織整個構建鏈條，在官方的核心只提供幾個方法，你們基於官方API來編寫本身須要的處理插件，再組合起來，完成構建功能。和Grunt的基本理念很像，可是不少又有區分，例如：配置和運行分離，插件單一職責，規定大於配置等等。關於這兩個的比較有不少，你們能夠搜搜Grunt Gulp 就知道了。很少說

• 新的王者Webpack，我的感受應該是15年上半年到16年初，Webpack橫空出世，大有一舉統一整個前端構建生態的趨勢，貌似如今FE們不會點Webpack相關的，都很差意思說本身是前端了。最初Webpack應該只是和requirejs、browserify之類模塊化工具比對，可是其靈活的API和豐富的loader，導致它能夠連帶完成Gulp之類的構建事件，目前其生態環境巨好，各類插件層出不窮，比較火的React，vuejs等都有相關的針對性loader來優化構建方式，能夠說是目前最流行的工具。不過缺點也特別的明顯，就是難懂，主要是過於靈活，各類方式都能接受，致使沒有一個統一的標準，配置起來特別難受，在羣裏，通常對於Webpack的配置問題的是最多的。不少新手對於Webpack的各類配置錯誤，感受都欲哭無淚，想死的心都有了。相關的文章也不少，推薦題葉的入門指南。

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

就我我的而言，目前主要仍是使用的Webpack來構建，固然一些比較老的系統代碼，因爲歷史緣由，仍是使用的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/'));
});

上面是我曾經本身配置的一個打包構建gulpfile，裏面作了上述我提到的全部事情，除了js模塊化打包以外，這個你們能夠本身研究下，比較簡單。我來解釋下各個任務的做用。

• default， 主要是監聽less變化生成css。

• clean， 清除掉publish文件夾的內容

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

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

• publish，根據上面 revision生成的新的md5文件來作一次文件替換，替換裏面js，css，image的引用路徑。

其實有些地方能夠優化的，這個你們有時間能夠本身去試試。

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