上一章講到了安裝好了路由，狀態管理和elementUI，那么這章要做的內容就是把項目架構完善一下，所謂欲先善其事、必先利其器，好的項目框架能幫助我們在開發的時候能做到事半功倍。那么就正式進入正題吧。
一、增加編碼規則校驗
上一章我們有講到因為eslint校驗規則導致無法正常運行的問題，我們的解決方法是暫時不管它，因為當時我們要講的重點不是它。
*************引用部分-start*************************
先給大家解釋一下編碼規則，每個程序員都有自己的編碼習慣，最常見的莫過於：
- 有的人寫代碼一行代碼結尾必須加分號
;，有的人覺得不加分號;更好看； - 有的人寫代碼一行代碼不會超過 80 個字符，認為這樣看起來簡潔明了，有的人喜歡把所有邏輯都寫在一行代碼上，覺得別人看不懂的代碼很牛逼；
- 有的人使用變量必然會先定義
var a = 10;，而粗心的人寫變量可能沒有定義過就直接使用b = 10;
如果你寫自己的項目怎么折騰都沒關系，但是在公司中老板希望每個人寫出的代碼都要符合一個統一的規則，這樣別人看源碼就能夠看得懂，因為源碼是符合統一的編碼規范制定的。
那么問題來了，總不能每個人寫的代碼老板都要一行行代碼去檢查吧，這是一件很蠢的事情。凡是重復性的工作，都應該被制作成工具來節約成本。這個工具應該做兩件事情：
- 提供編碼規范；
- 提供自動檢驗代碼的程序，並打印檢驗結果：告訴你哪一個文件哪一行代碼不符合哪一條編碼規范，方便你去修改代碼。
而Lint 是檢驗代碼格式工具的一個統稱，具體的工具有 Jslint 、 Eslint 等等 ...........
我們可以形象地將 Lint 看成是電商行業，而電商行業具體表現有淘寶（Eslint）、京東（Jslint）等。
（上面內容引用自簡書：https://www.jianshu.com/p/ad1e46faaea2）
***************引用部分-end**********************
那么我們下面說一下怎么讓項目架構做到統一規范，讓參與開發的小組成員都能遵循一套規則去進行。
不知道大家還記不記得，我們在第一章的時候通過Vue腳手架創建項目的時候，就已經安裝有eslint了，但是只有在代碼被編譯的時候才會報錯，那能不能在編寫代碼的時候就能提示錯誤呢？
VSCode 安裝 Eslint 和 Prettier 插件，用於校驗語法統一代碼格式。
安裝完成之后，我們把加在package.json 中的校驗規則去掉：
{ "name": "fst-backstage-system", "version": "0.1.0", "private": true, "scripts": { "serve": "vue-cli-service serve", "build": "vue-cli-service build", "lint": "vue-cli-service lint" }, "dependencies": { "core-js": "^3.6.5", "element-ui": "^2.15.7", "vue": "^2.6.11", "vue-router": "^3.5.3", "vuex": "^3.6.2" }, "devDependencies": { "@vue/cli-plugin-babel": "~4.5.0", "@vue/cli-plugin-eslint": "~4.5.0", "@vue/cli-service": "~4.5.0", "babel-eslint": "^10.1.0", "eslint": "^6.7.2", "eslint-plugin-vue": "^6.2.2", "vue-template-compiler": "^2.6.11" }, "browserslist": [ "> 1%", "last 2 versions", "not dead" ] }
然后我們在項目根目錄下創建.eslintrc.js，主要是方便管理，添加下面的代碼：
module.exports = { root: true, globals: { window: true, }, env: { commonjs: true, browser: true, es6: true, }, extends: ['eslint:recommended', 'plugin:vue/essential'], parserOptions: { ecmaVersion: 10, sourceType: 'module', }, plugins: ['vue'], rules: { semi: ['error', 'never'], quotes: ['error', 'single', { allowTemplateLiterals: true }], 'no-console': 1, 'no-debugger': 1, 'vue/multi-word-component-names': 0, }, }
添加之后，我們就可以看到，項目中一些文件都已經報紅了：
說明編碼規則檢測已經在進行了，當然也可以不管它，因為它不會影響正常編譯和發布。
說明一些現在加入的規則：
- 句末不能有分號
- 不能有不使用的參數
- 字符串用單引號
- 不能有console
- 不能有debugger
當然這些規則都是可以更改的，那就看大家的習慣了。
我們現在在編譯器中加入校驗規則檢測，那么像現在已經寫好的文件，報紅色部分怎么解決呢？我們直接格式化代碼就好，用的就是上面安裝的Prettier插件：
首先需要選擇默認的格式化工具：在編輯器空白處右鍵->選擇“使用.....格式化文檔”->然后選擇Prettier就好了（選擇之后，以后直接使用“格式化文檔”選項就好了）
其中Prettier代碼格式化也是可以根據開發者愛好自定義的，在項目根目錄下創建.prettierrc.js就能實現在該項目使用格式化的規范了，比如：
module.exports = { "semi": false, //在代碼格式化的時候不加分號 "singleQuote": true, //字符串為單引號 "tabWidth": 4, //縮進4個字符 "printWidth": 600, // }
代碼校驗的講完了，下面我們學習一下關於vue.config.js。
二、創建vue.config.js
熟悉Vue的同學都知道，Vue的擴展性都能通過vue.config.js來配置。
但是現在使用腳手架3以上的版本創建之后項目，這個文件是沒有的，需要手動創建（后面講到的很多內容都需要這個文件配合的）。
那么我們現在根目錄下創建vue.config.js文件：
module.exports = { publicPath: './', productionSourceMap: false, // 生產源映射 runtimeCompiler: true, // 設置熱更新 };
publicPath使用相對路徑 ('./')，這樣所有的資源都會被鏈接為相對路徑，這樣打出來的包可以被部署在任意路徑，也可以用在類似 Cordova hybrid 應用的文件系統中。
好了，這章今天就先講到這里吧，下一章我們將繼續完善src文件夾下的架構。