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

乖小鬼YQ發表於2019-02-16
前端開發環境

文章來源

最近幾年，前端發展越來越迅速，各種萌新加入了前端這個大家庭，大有趕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為主，來解釋它的配置方案。

相關文章