團隊開發的項目，如果沒有對代碼風格作要求，有多少團隊成員，就當然會出現多少種不同的代碼風格。因此，我們需要一種能夠統一團隊代碼風格的工具，作為強制性的規范，統一整個項目的代碼風格。

幸好，我們有 eslint 和 prettier 。

eslint VS prettier

應該大多數項目都已經采用eslint來對代碼進行質量檢查，可能少部分還會采用其進行一定程度上的統一風格。那為什么還需要prettier呢？我們先來對它們作一個簡單的了解。

各種linters

總體來說，linters有兩種能力：

檢查代碼質量 ，比如是否有已定義但未使用的變量，或者使用函數式編程的函數是否產生副作用等。 檢查代碼風格 ，比如每行的最大長度，或者是否使用拖尾逗號等。

其中，eslint文檔中，帶扳手圖標的規則就是eslint能夠自動修復的規則。而不帶該圖標的規則，eslint則只能給出錯誤或警告，隨后由開發者人工修復。

prettier

pretter沒有對代碼的質量進行檢查的能力，其只會對代碼風格按照指定的規范進行統一，避免一個項目中出現多種不同的代碼風格。

項目配置

此處使用vue項目作為例子

一、首先配置eslint

如果大家的項目是使用vue cli生成的，并且選擇使用eslint的話，那么默認在項目根目錄下就會生成.eslintrc.js。如果沒有，也可以在項目根目錄下創建該文件以及.eslintignore文件

此處我使用eslint-plugin-vue，選擇的是vue/strongly-recommended規則。

npm install --save-dev eslint eslint-plugin-vue@next// .eslintrc.jsextends: {  'plugin:vue/strongly-recommended'}// .eslintignore/build//config//dist//*.js/test/unit/coverage/

如果希望在重新編譯的時候eslint自動修復代碼，需要在webpack配置中加入eslint，并且設置 fix: true ，并且在devserver中開啟eslint。

// config/index.jsmodule.exports = { dev: {  useEslint: true,  }}// webpack.base.conf.jsconst createLintingRule = () => ({ test: //.(js|vue)$/, loader: 'eslint-loader', enforce: 'pre', include: [resolve('src'), resolve('test')], options: {  formatter: require('eslint-friendly-formatter'),  emitWarning: !config.dev.showEslintErrorsInOverlay,  fix: true, }})

二、配置prettier

由于使用eslint，并不能最大程度地統一代碼風格，因此我們需要引入prettier。

npm install --save-dev prettier

按照實際需要配置prettier

//prettier.config.js

module.exports = {  "printWidth": 80, // 每行代碼長度（默認80） "tabWidth": 2, // 每個tab相當于多少個空格（默認2） "useTabs": false, // 是否使用tab進行縮進（默認false） "singleQuote": true, // 使用單引號（默認false） "semi": true, // 聲明結尾使用分號(默認true) "trailingComma": "all", // 多行使用拖尾逗號（默認none） "bracketSpacing": true, // 對象字面量的大括號間使用空格（默認true） "jsxBracketSameLine": false, // 多行JSX中的>放置在最后一行的結尾，而不是另起一行（默認false） "arrowParens": "avoid" // 只有一個參數的箭頭函數的參數是否帶圓括號（默認avoid）};