摘要：從到再到搭建編寫構(gòu)建一個(gè)前端項(xiàng)目選擇現(xiàn)成的項(xiàng)目模板還是自己搭建項(xiàng)目骨架搭建一個(gè)前端項(xiàng)目的方式有兩種選擇現(xiàn)成的項(xiàng)目模板自己搭建項(xiàng)目骨架。使用版本控制系統(tǒng)管理源代碼項(xiàng)目搭建好后，需要一個(gè)版本控制系統(tǒng)來管理源代碼。

搭建一個(gè)前端項(xiàng)目的方式有兩種：選擇現(xiàn)成的項(xiàng)目模板、自己搭建項(xiàng)目骨架。

選擇一個(gè)現(xiàn)成項(xiàng)目模板是搭建一個(gè)項(xiàng)目最快的方式，模板已經(jīng)把基本的骨架都搭建好了，你只需要向里面填充具體的業(yè)務(wù)代碼，就可以通過內(nèi)置的工具與命令構(gòu)建代碼、部署到服務(wù)器等。

一般來說，一個(gè)現(xiàn)成的項(xiàng)目模板會預(yù)定義一定的目錄結(jié)構(gòu)、書寫方式，在編寫項(xiàng)目代碼時(shí)需要遵循相應(yīng)的規(guī)范；也會內(nèi)置必要的工具，比如 .editorconfig、eslint、stylelint、prettier、husky、lint-staged 等；也會內(nèi)置必要的命令（package.json | scripts），比如 本地開發(fā)：npm run dev、本地預(yù)覽：npm run start、構(gòu)建：npm run build、部署：npm run deploy 等。

社區(qū)比較好的項(xiàng)目模板：

react-boilerplate

ant-design-pro

vue-element-admin

react-starter-kit

create-react-app

create-lila-app（我自己用的，哈哈）

這些模板的使用又分為兩種：使用 git 直接克隆到本地、使用命令行創(chuàng)建。

（使用現(xiàn)有模板構(gòu)建的項(xiàng)目，可以跳過第 2 ～ 7 步）

這是一種真正意義上的模板，可以直接到模板項(xiàng)目的 github 主頁，就能看到整個(gè)骨架，比如 react-boilerplate、ant-design-pro、vue-element-admin、react-starter-kit。

以 react-boilerplate 為例：

克隆到本地：

git clone --depth=1 https://github.com/react-boilerplate/react-boilerplate.git <你的項(xiàng)目名字>

切換到目錄下：

cd <你的項(xiàng)目名字>

一般來說，接下來運(yùn)行 npm run install 安裝項(xiàng)目的依賴后，就可以運(yùn)行；有些模板可能有內(nèi)置的初始化命令，比如 react-boilerplate：

npm run setup

啟動應(yīng)用：

npm start

這時(shí)，就可以在瀏覽器中預(yù)覽應(yīng)用了。

這種方式需要安裝相應(yīng)的命令，然后由命令來創(chuàng)建項(xiàng)目。

以 create-react-app 為例：

安裝命令：

npm install -g create-react-app

創(chuàng)建項(xiàng)目：

create-react-app my-app

運(yùn)行應(yīng)用：

cd my-app
npm start

如果你需要定制化，可以選擇自己搭建項(xiàng)目的骨架，但這需要開發(fā)者對構(gòu)建工具如 webpack、npm、node 及其生態(tài)等有相當(dāng)?shù)牧私馀c應(yīng)用，才能完美的把控整個(gè)項(xiàng)目。

下面將會一步一步的說明如何搭建一個(gè)定制化的項(xiàng)目骨架。

js 模塊化的發(fā)展大致有這樣一個(gè)過程 iife => commonjs/amd => es6，而在這幾個(gè)規(guī)范中：

iife: js 原生支持，但一般不會直接使用這種規(guī)范寫代碼

amd: requirejs 定義的加載規(guī)范，但隨著構(gòu)建工具的出現(xiàn)，便一般不會用這種規(guī)范寫代碼

commonjs: node 的模塊加載規(guī)范，一般會用這種規(guī)范寫 node 程序

es6: ECMAScript2015 定義的模塊加載規(guī)范，需要轉(zhuǎn)碼后瀏覽器才能運(yùn)行

這里推薦使用 es6 的模塊化規(guī)范來寫代碼，然后用工具轉(zhuǎn)換成 es5 的代碼，并且 es6 的代碼可以使用 Tree shaking 功能。

參考：

IIFE(Immediately-invoked function expression)

Tree shaking

webpack - tree-shaking

webpack 如何優(yōu)雅的使用tree-shaking（搖樹優(yōu)化）

對于前端項(xiàng)目來說，構(gòu)建工具一般都選用 webpack，webpack 提供了強(qiáng)大的功能和配置化運(yùn)行。如果你不喜歡復(fù)雜的配置，可以嘗試 parcel。

參考：

webpack 之外的另一種選擇：parcel

因?yàn)閱雾撁鎽?yīng)用與多頁面應(yīng)用在構(gòu)建的方式上有很大的不同，所以需要從項(xiàng)目一開始就確定，使用哪種模式來構(gòu)建項(xiàng)目。

傳統(tǒng)多頁面是由后端控制一個(gè) url 對應(yīng)一個(gè) html 文件，頁面之間的跳轉(zhuǎn)需要根據(jù)后端給出的 url 跳轉(zhuǎn)到新的 html 上。比如：

http://www.example.com/page1 -> path/to/page1.html
http://www.example.com/page2 -> path/to/page2.html
http://www.example.com/page3 -> path/to/page3.html

這種方式的應(yīng)用，項(xiàng)目里會有多個(gè)入口文件，搭建項(xiàng)目的時(shí)候就需要對這種多入口模式進(jìn)行封裝。另外，也可以選擇一些封裝的多入口構(gòu)建工具，如 lila。

單頁面應(yīng)用（single page application），就是只有一個(gè)頁面的應(yīng)用，頁面的刷新和內(nèi)部子頁面的跳轉(zhuǎn)完全由 js 來控制。

一般單頁面應(yīng)用都有以下幾個(gè)特點(diǎn)：

本地路由，由 js 定義路由、根據(jù)路由渲染頁面、控制頁面的跳轉(zhuǎn)

所有文件只會加載一次，最大限度重用文件，并且極大提升加載速度

按需加載，只有真正使用到頁面的時(shí)候，才加載相應(yīng)的文件

這種方式的應(yīng)用，項(xiàng)目里只有一個(gè)入口文件，便無需封裝。

參考：

單頁面應(yīng)用（SPA）、按需加載

一般在搭建項(xiàng)目的時(shí)候就需要定下前端框架與 UI 庫，因?yàn)槿绻笃谙敫鼡Q前端框架和 UI 庫，代價(jià)是很大的。

比較現(xiàn)代化的前端框架：

react

vue

angular

一些不錯的組合：

jquery + bootstrap：比較經(jīng)典的

react + ant-design、material-ui、Semantic-UI：react 的組合

vue + element、iview、vux、mint-ui：vue 的組合

參考：

前端最受歡迎的 UI 框架

一個(gè)好的目錄結(jié)構(gòu)對一個(gè)好的項(xiàng)目而言是非常必要的。

一個(gè)好的目錄結(jié)構(gòu)應(yīng)當(dāng)具有以下的一些特點(diǎn)：

解耦：代碼盡量去耦合，這樣代碼邏輯清晰，也容易擴(kuò)展

分塊：按照功能對代碼進(jìn)行分塊、分組，并能快捷的添加分塊、分組

編輯器友好：需要更新功能時(shí)，可以很快的定位到相關(guān)文件，并且這些文件應(yīng)該是很靠近的，而不至于到處找文件

比較推薦的目錄結(jié)構(gòu)：

多頁面應(yīng)用

|-- src/ 源代碼目錄

    |-- page1/ page1 頁面的工作空間（與這個(gè)頁面相關(guān)的文件都放在這個(gè)目錄下）
        |-- index.html html 入口文件
        |-- index.js js 入口文件
        |-- index.(css|less|scss) 樣式入口文件
        |-- html/ html 片段目錄
        |-- (css|less|scss)/ 樣式文件目錄
        |-- mock/ 本地 json 數(shù)據(jù)模擬
        |-- images/ 圖片文件目錄
        |-- components/ 組件目錄（如果基于 react, vue 等組件化框架）
        |-- ...
        
    |-- sub-dir/ 子目錄
        |-- page2/ page2 頁面的工作空間（內(nèi)部結(jié)構(gòu)參考 page1）
            |-- ...
        
    |-- ...
    
|-- html/ 公共 html 片段
|-- less/ 公共 less 目錄
|-- components/ 公共組件目錄
|-- images/ 公共圖片目錄
|-- mock/ 公共 api-mock 文件目錄
|-- ...

單頁面應(yīng)用

|-- src/ 源代碼目錄
    |-- page1/ page1 頁面的工作空間
        |-- index.js 入口文件
        |-- services/ service 目錄
        |-- models/ model 目錄
        |-- mock/ 本地 json 數(shù)據(jù)模擬
        |-- images/ 圖片文件目錄
        |-- components/ 組件目錄（如果基于 react, vue 等組件化框架）
        |-- ...
        
    |-- module1/ 子目錄
        |-- page2/ page2 頁面的工作空間（內(nèi)部結(jié)構(gòu)參考 page1）
        
    |-- ...
    
|-- images/ 公共圖片目錄
|-- mock/ 公共 api-mock 文件目錄
|-- components/ 公共組件目錄   
|-- ... 

參考：

目錄結(jié)構(gòu)優(yōu)化

搭建一個(gè)好的腳手架，能夠更好的編寫代碼、構(gòu)建項(xiàng)目等。

可以查看 搭建自己的前端腳手架 了解一些基本的腳手架文件與工具。

比如：

|-- /                              項(xiàng)目根目錄
    |-- src/                       源代碼目錄
    |-- package.json               npm 項(xiàng)目文件
    |-- README.md                  項(xiàng)目說明文件
    |-- CHANGELOG.md               版本更新記錄
    |-- .gitignore                 git 忽略配置文件
    |-- .editorconfig              編輯器配置文件
    |-- .npmrc                     npm 配置文件
    |-- .npmignore                 npm 忽略配置文件
    |-- .eslintrc                  eslint 配置文件
    |-- .eslintignore              eslint 忽略配置文件
    |-- .stylelintrc               stylelint 配置文件
    |-- .stylelintignore           stylelint 忽略配置文件
    |-- .prettierrc                prettier 配置文件
    |-- .prettierignore            prettier 忽略配置文件
    
    |-- .babelrc                   babel 配置文件
    |-- webpack.config.js          webpack 配置文件
    |-- rollup.config.js           rollup 配置文件
    |-- gulpfile.js                gulp 配置文件
    
    |-- test/                      測試目錄
    |-- docs/                      文檔目錄
    |-- jest.config.js             jest 配置文件
    |-- .gitattributes             git 屬性配置

.editorconfig: 用這個(gè)文件來統(tǒng)一不同編輯器的一些配置，比如 tab 轉(zhuǎn) 2 個(gè)空格、自動插入空尾行、去掉行尾的空格等，http://editorconfig.org

eslint、stylelint、prettier: 規(guī)范化代碼風(fēng)格、優(yōu)化代碼格式等

husky、lint-staged: 在 git 提交之前對代碼進(jìn)行審查，否則不予提交

.gitlab-ci.yml: gitlab ci 持續(xù)集成服務(wù)

參考：

搭建自己的前端腳手架

怎樣提升代碼質(zhì)量

CSS 模塊化

css 的弱化與 js 的強(qiáng)化

本地化接口模擬、前后端并行開發(fā)

=================================================

到這里為止，一個(gè)基本的項(xiàng)目骨架就算搭建好了。

項(xiàng)目搭建好后，需要一個(gè)版本控制系統(tǒng)來管理源代碼。

比較常用的版本管理工具有 git、svn，現(xiàn)在一般都用 git。

一般開源的項(xiàng)目可以托管到 http://github.com，私人的項(xiàng)目可以托管到 https://gitee.com、https://coding.net/，而企業(yè)的項(xiàng)目則需要自建版本控制系統(tǒng)了。

自建版本控制系統(tǒng)主要有 gitlab、gogs、gitea：gitlab 是由商業(yè)驅(qū)動的，比較穩(wěn)定，社區(qū)版是免費(fèi)的，一般建議選用這個(gè)；gogs, gitea 是開源的項(xiàng)目，還不太穩(wěn)定，期待進(jìn)一步的更新。

所以，git + gitlab 是不錯的配合。

編寫代碼時(shí)，js 選用 es6 的模塊化規(guī)范來寫（如果喜歡用 TypeScript，需要加上 ts-loader），樣式可以用 less、scss、css 來寫。

寫 js 模塊文件時(shí)，注釋可以使用 jsdoc 的規(guī)范來寫，如果配置相應(yīng)的工具，可以將這些注釋導(dǎo)出接口文檔。

因?yàn)槟_手架里有 husky、lint-staged 的配合，所以每次提交的代碼都會進(jìn)行代碼審查與格式優(yōu)化，如果不符合規(guī)范，則需要把不規(guī)范的代碼進(jìn)行修改，然后才能提交到代碼倉庫中。

比如 console.log(haha.hehe); 這段代碼就會遇到錯誤，不予提交：

這個(gè)功能定義在 package.json 中：

{
  "devDependencies": {             工具依賴
    "babel-eslint": "^8.2.6",
    "eslint": "^4.19.1",
    "husky": "^0.14.3",
    "lint-staged": "^7.2.0",
    "prettier": "^1.14.0",
    "stylelint": "^9.3.0",
    "eslint-config-airbnb": "^17.0.0",
    "eslint-config-prettier": "^2.9.0",
    "eslint-plugin-babel": "^5.1.0",
    "eslint-plugin-import": "^2.13.0",
    "eslint-plugin-jsx-a11y": "^6.1.0",
    "eslint-plugin-prettier": "^2.6.2",
    "eslint-plugin-react": "^7.10.0",
    "stylelint-config-prettier": "^3.3.0",
    "stylelint-config-standard": "^18.2.0"
  },
  "scripts": {                     可以添加更多命令
    "precommit": "npm run lint-staged",
    "prettier": "prettier --write "./**/*.{js,jsx,css,less,sass,scss,md,json}"",
    "eslint": "eslint .",
    "eslint:fix": "eslint . --fix",
    "stylelint": "stylelint "./**/*.{css,less,sass,scss}"",
    "stylelint:fix": "stylelint "./**/*.{css,less,sass,scss}" --fix",
    "lint-staged": "lint-staged"
  },
  "lint-staged": {                 對提交的代碼進(jìn)行檢查與矯正
    "**/*.{js,jsx}": [
      "eslint --fix",
      "prettier --write",
      "git add"
    ],
    "**/*.{css,less,sass,scss}": [
      "stylelint --fix",
      "prettier --write",
      "git add"
    ],
    "**/*.{md,json}": [
      "prettier --write",
      "git add"
    ]
  }
}

如果你想禁用這個(gè)功能，可以把 scripts 中 "precommit" 改成 "http://precommit"

如果你想自定 eslint 檢查代碼的規(guī)范，可以修改 .eslintrc, .eslintrc.js 等配置文件

如果你想自定 stylelint 檢查代碼的規(guī)范，可以修改 .stylelintrc, .stylelintrc.js 等配置文件

如果你想忽略某些文件不進(jìn)行代碼檢查，可以修改 .eslintignore, .stylelintignore 配置文件

參考：

搭建自己的前端腳手架

當(dāng)項(xiàng)目擁有了一定量的代碼之后，就會發(fā)現(xiàn)，有些代碼是很多頁面共用的，于是把這些代碼提取出來，封裝成一個(gè)組件，供各個(gè)地方使用。

當(dāng)擁有多個(gè)項(xiàng)目的時(shí)候，有些組件需要跨項(xiàng)目使用，一種方式是復(fù)制代碼到其他項(xiàng)目中，但這種方式會導(dǎo)致組件代碼很難維護(hù)，所以，一般是用另一種方式：組件化。

組件化就是將組件獨(dú)立成一個(gè)項(xiàng)目，然后在其他項(xiàng)目中安裝這個(gè)組件，才能使用。

一般組件化會配合私有 npm 倉庫一起用。

|-- project1/ 項(xiàng)目1
    |-- package.json
    
|-- project2/ 項(xiàng)目2
    |-- package.json    

|-- component1/ 組件1
    |-- package.json

|-- component2/ 組件2
    |-- package.json

在 project1 中安裝 component1， component2 組件：

# package.json
{
  "dependencies": {
    "component1": "^0.0.1",
    "component2": "^0.0.1"
  }
}

import compoennt1 from "compoennt1";
import compoennt2 from "compoennt2";

如果想要了解怎樣寫好一個(gè)組件（npm package），可以參考 從 1 到完美，寫一個(gè) js 庫、node 庫、前端組件庫。

參考：

組件化

私有 npm 倉庫

從 1 到完美，寫一個(gè) js 庫、node 庫、前端組件庫

測試的目的在于能以最少的人力和時(shí)間發(fā)現(xiàn)潛在的各種錯誤和缺陷，這在項(xiàng)目更新、重構(gòu)等的過程中尤其重要，因?yàn)槊慨?dāng)更改一些代碼后，你并不知道這些代碼有沒有問題、會不會影響其他的模塊。如果有了測試，運(yùn)行一遍測試用例，就知道更改的代碼有沒有問題、會不會產(chǎn)生影響。

一般前端測試分以下幾種：

單元測試：模塊單元、函數(shù)單元、組件單元等的單元塊的測試

集成測試：接口依賴（ajax）、I/O 依賴、環(huán)境依賴（localStorage、IndexedDB）等的上下文的集成測試

樣式測試：對樣式的測試

E2E 測試：端到端測試，也就是在實(shí)際生產(chǎn)環(huán)境測試整個(gè)應(yīng)用

一般會用到下面的一些工具：

jest

enzyme

cypress

selenium

puppeteer

另外，可以參考 聊聊前端開發(fā)的測試。

一般單頁面應(yīng)用的構(gòu)建會有 npm run build 的命令來構(gòu)建項(xiàng)目，然后會輸出一個(gè) html 文件，一些 js/css/images ... 文件，然后把這些文件部署到服務(wù)器就可以了。

多頁面應(yīng)用的構(gòu)建要復(fù)雜一些，因?yàn)槭嵌嗳肟诘?，所以一般會封裝構(gòu)建工具，然后通過參數(shù)傳入多個(gè)入口：

npm run build -- page1 page2 dir1/* dir2/all --env test/prod

page1, page2 確定構(gòu)建哪些頁面；dir1/*, dir2/all 某個(gè)目錄下所有的頁面；all, * 整個(gè)項(xiàng)目所有的頁面

有時(shí)候可能還會針對不同的服務(wù)器環(huán)境（比如測試機(jī)、正式機(jī)）做出不同的構(gòu)建，可以在后面加參數(shù)

-- 用來分割 npm 本身的參數(shù)與腳本參數(shù)，參考 npm - run-script 了解詳情

多頁面應(yīng)用會導(dǎo)出多個(gè) html 文件，需要注意這些導(dǎo)出的 html 不要相沖突了。

當(dāng)然，也可以用一些已經(jīng)封裝好的工具，如 lila。

在構(gòu)建好項(xiàng)目之后，就可以部署到服務(wù)器了。

傳統(tǒng)的方式，可以用 ftp, sftp 等工具，手動傳到服務(wù)器，但這種方式比較笨拙，不夠自動化。

自動化的，可以用一些工具部署到服務(wù)器，如 gulp、gulp-ssh，當(dāng)然也可以用一些封裝的工具，如 md-sync、lila 等

以 md-sync 為例：

npm install md-sync --save-dev

md-sync.config.js 配置文件：

module.exports = [
  {
    src: "./build/**/*",
    remotePath: "remotePath",
    server: {
      ignoreErrors: true,
      sshConfig: {
        host: "host",
        username: "username",
        password: "password"
      }
    },
  },
  {
    src: "./build/**/*.html",
    remotePath: "remotePath2",
    server: {
      ignoreErrors: true,
      sshConfig: {
        host: "host",
        username: "username",
        password: "password"
      }
    },
  },
];

在 package.json 的 scripts 配置好命令：

"scripts": {
  "deploy": "md-sync"
}

npm run deploy

另外，一般大型項(xiàng)目會使用持續(xù)集成 + shell 命令（如 rsync）部署。

一般大型工程的的構(gòu)建與測試都會花很長的時(shí)間，在本地做這些事情的話就不太實(shí)際，這就需要做持續(xù)集成測試、構(gòu)建、部署了。

持續(xù)集成工具用的比較多的：

jenkins

gitlab ci

jenkins 是通用型的工具，可以與 github、bitbucket、gitlab 等代碼托管服務(wù)配合使用，優(yōu)點(diǎn)是功能強(qiáng)大、插件多、社區(qū)活躍，但缺點(diǎn)是配置復(fù)雜、使用難度較高。

gitlab ci 是 gitlab 內(nèi)部自帶的持續(xù)集成功能，優(yōu)點(diǎn)是使用簡單、配置簡單，但缺點(diǎn)是不及 jenkins 功能強(qiáng)大、綁定 gitlab 才能使用。

以 gitlab 為例（任務(wù)定義在 .gitlab-ci.yml 中）：

stages:
  - install
  - test
  - build
  - deploy

# 安裝依賴
install:
  stage: install
  only:
    - dev
    - master
  script:
    - npm install

# 運(yùn)行測試用例
test:
  stage: test
  only:
    - dev
    - master
  script:
    - npm run test

# 編譯
build:
  stage: build
  only:
    - dev
    - master
  script:
    - npm run clean
    - npm run build

# 部署服務(wù)器
deploy:
  stage: deploy
  only:
    - dev
    - master
  script:
    - npm run deploy

以上配置表示只要在 dev 或 master 分支有代碼推送，就會進(jìn)行持續(xù)集成，依次運(yùn)行：

npm install

npm run test

npm run clean

npm run build

npm run deploy

最終完成部署。如果中間某個(gè)命令失敗了，將停止接下的命令的運(yùn)行，并將錯誤報(bào)告給你。

這些操作都在遠(yuǎn)程機(jī)器上完成。

=================================================

到這里為止，基本上完成了一個(gè)項(xiàng)目的搭建、編寫、構(gòu)建。

現(xiàn)在前端的項(xiàng)目基本上都會用 webpack 打包代碼，并且文件名（html 文件除外）都是 hash 化的，如果需要清除過期的文件而又不想把服務(wù)器上文件全部刪掉然后重新構(gòu)建、部署，可以使用 sclean 來清除過期文件。

當(dāng)用戶在用線上的程序時(shí)，怎么知道有沒有出 bug；如果出 bug 了，報(bào)的是什么錯；如果是 js 報(bào)錯，怎么知道是那一行運(yùn)行出了錯？

所以，在程序運(yùn)行時(shí)捕捉 js 腳本錯誤，并上報(bào)到服務(wù)器，是非常有必要的。

這里就要用到 window.onerror 了：

window.onerror = (errorMessage, scriptURI, lineNumber, columnNumber, errorObj) => {
  const data = {
    title: document.getElementsByTagName("title")[0].innerText,
    errorMessage,
    scriptURI,
    lineNumber,
    columnNumber,
    detailMessage: (errorObj && errorObj.message) || "",
    stack: (errorObj && errorObj.stack) || "",
    userAgent: window.navigator.userAgent,
    locationHref: window.location.href,
    cookie: window.document.cookie,
  };

  post("url", data); // 上報(bào)到服務(wù)器
};

線上的 js 腳本都是壓縮過的，需要用 sourcemap 文件與 source-map 查看原始的報(bào)錯堆棧信息，可以參考 細(xì)說 js 壓縮、sourcemap、通過 sourcemap 查找原始報(bào)錯信息 了解詳細(xì)信息。

參考：

前端如何高效的與后端協(xié)作開發(fā)

細(xì)說 js 壓縮、sourcemap、通過 sourcemap 查找原始報(bào)錯信息

更多博客，查看 https://github.com/senntyou/blogs

作者：深予之 (@senntyou)

版權(quán)聲明：自由轉(zhuǎn)載-非商用-非衍生-保持署名（創(chuàng)意共享3.0許可證）