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

搭建一個前端項目的方式有兩種：選擇現成的項目模板、自己搭建項目骨架。

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

一般來說，一個現成的項目模板會預定義一定的目錄結構、書寫方式，在編寫項目代碼時需要遵循相應的規范；也會內置必要的工具，比如 .editorconfig、eslint、stylelint、prettier、husky、lint-staged 等；也會內置必要的命令（package.json | scripts），比如 本地開發：npm run dev、本地預覽：npm run start、構建：npm run build、部署：npm run deploy 等。

社區比較好的項目模板：

react-boilerplate

ant-design-pro

vue-element-admin

react-starter-kit

create-react-app

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

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

（使用現有模板構建的項目，可以跳過第 2 ～ 7 步）

這是一種真正意義上的模板，可以直接到模板項目的 github 主頁，就能看到整個骨架，比如 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 <你的項目名字>

切換到目錄下：

cd <你的項目名字>

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

npm run setup

啟動應用：

npm start

這時，就可以在瀏覽器中預覽應用了。

這種方式需要安裝相應的命令，然后由命令來創建項目。

以 create-react-app 為例：

安裝命令：

npm install -g create-react-app

創建項目：

create-react-app my-app

運行應用：

cd my-app
npm start

如果你需要定制化，可以選擇自己搭建項目的骨架，但這需要開發者對構建工具如 webpack、npm、node 及其生態等有相當的了解與應用，才能完美的把控整個項目。

下面將會一步一步的說明如何搭建一個定制化的項目骨架。

js 模塊化的發展大致有這樣一個過程 iife => commonjs/amd => es6，而在這幾個規范中：

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

amd: requirejs 定義的加載規范，但隨著構建工具的出現，便一般不會用這種規范寫代碼

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

es6: ECMAScript2015 定義的模塊加載規范，需要轉碼后瀏覽器才能運行

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

參考：

IIFE(Immediately-invoked function expression)

Tree shaking

webpack - tree-shaking

webpack 如何優雅的使用tree-shaking（搖樹優化）

對于前端項目來說，構建工具一般都選用 webpack，webpack 提供了強大的功能和配置化運行。如果你不喜歡復雜的配置，可以嘗試 parcel。

參考：

webpack 之外的另一種選擇：parcel

因為單頁面應用與多頁面應用在構建的方式上有很大的不同，所以需要從項目一開始就確定，使用哪種模式來構建項目。

傳統多頁面是由后端控制一個 url 對應一個 html 文件，頁面之間的跳轉需要根據后端給出的 url 跳轉到新的 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

這種方式的應用，項目里會有多個入口文件，搭建項目的時候就需要對這種多入口模式進行封裝。另外，也可以選擇一些封裝的多入口構建工具，如 lila。

單頁面應用（single page application），就是只有一個頁面的應用，頁面的刷新和內部子頁面的跳轉完全由 js 來控制。

一般單頁面應用都有以下幾個特點：

本地路由，由 js 定義路由、根據路由渲染頁面、控制頁面的跳轉

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

按需加載，只有真正使用到頁面的時候，才加載相應的文件

這種方式的應用，項目里只有一個入口文件，便無需封裝。

參考：

單頁面應用（SPA）、按需加載

一般在搭建項目的時候就需要定下前端框架與 UI 庫，因為如果后期想更換前端框架和 UI 庫，代價是很大的。

比較現代化的前端框架：

react

vue

angular

一些不錯的組合：

jquery + bootstrap：比較經典的

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

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

參考：

前端最受歡迎的 UI 框架

一個好的目錄結構對一個好的項目而言是非常必要的。

一個好的目錄結構應當具有以下的一些特點：

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

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

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

比較推薦的目錄結構：

多頁面應用

|-- src/ 源代碼目錄

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

單頁面應用

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

參考：

目錄結構優化

搭建一個好的腳手架，能夠更好的編寫代碼、構建項目等。

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

比如：

|-- /                              項目根目錄
    |-- src/                       源代碼目錄
    |-- package.json               npm 項目文件
    |-- README.md                  項目說明文件
    |-- 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: 用這個文件來統一不同編輯器的一些配置，比如 tab 轉 2 個空格、自動插入空尾行、去掉行尾的空格等，http://editorconfig.org

eslint、stylelint、prettier: 規范化代碼風格、優化代碼格式等

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

.gitlab-ci.yml: gitlab ci 持續集成服務

參考：

搭建自己的前端腳手架

怎樣提升代碼質量

CSS 模塊化

css 的弱化與 js 的強化

本地化接口模擬、前后端并行開發

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

到這里為止，一個基本的項目骨架就算搭建好了。

項目搭建好后，需要一個版本控制系統來管理源代碼。

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

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

自建版本控制系統主要有 gitlab、gogs、gitea：gitlab 是由商業驅動的，比較穩定，社區版是免費的，一般建議選用這個；gogs, gitea 是開源的項目，還不太穩定，期待進一步的更新。

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

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

寫 js 模塊文件時，注釋可以使用 jsdoc 的規范來寫，如果配置相應的工具，可以將這些注釋導出接口文檔。

因為腳手架里有 husky、lint-staged 的配合，所以每次提交的代碼都會進行代碼審查與格式優化，如果不符合規范，則需要把不規范的代碼進行修改，然后才能提交到代碼倉庫中。

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

這個功能定義在 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": {                 對提交的代碼進行檢查與矯正
    "**/*.{js,jsx}": [
      "eslint --fix",
      "prettier --write",
      "git add"
    ],
    "**/*.{css,less,sass,scss}": [
      "stylelint --fix",
      "prettier --write",
      "git add"
    ],
    "**/*.{md,json}": [
      "prettier --write",
      "git add"
    ]
  }
}

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

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

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

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

參考：

搭建自己的前端腳手架

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

當擁有多個項目的時候，有些組件需要跨項目使用，一種方式是復制代碼到其他項目中，但這種方式會導致組件代碼很難維護，所以，一般是用另一種方式：組件化。

組件化就是將組件獨立成一個項目，然后在其他項目中安裝這個組件，才能使用。

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

|-- project1/ 項目1
    |-- package.json
    
|-- project2/ 項目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";

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

參考：

組件化

私有 npm 倉庫

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

測試的目的在于能以最少的人力和時間發現潛在的各種錯誤和缺陷，這在項目更新、重構等的過程中尤其重要，因為每當更改一些代碼后，你并不知道這些代碼有沒有問題、會不會影響其他的模塊。如果有了測試，運行一遍測試用例，就知道更改的代碼有沒有問題、會不會產生影響。

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

單元測試：模塊單元、函數單元、組件單元等的單元塊的測試

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

樣式測試：對樣式的測試

E2E 測試：端到端測試，也就是在實際生產環境測試整個應用

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

jest

enzyme

cypress

selenium

puppeteer

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

一般單頁面應用的構建會有 npm run build 的命令來構建項目，然后會輸出一個 html 文件，一些 js/css/images ... 文件，然后把這些文件部署到服務器就可以了。

多頁面應用的構建要復雜一些，因為是多入口的，所以一般會封裝構建工具，然后通過參數傳入多個入口：

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

page1, page2 確定構建哪些頁面；dir1/*, dir2/all 某個目錄下所有的頁面；all, * 整個項目所有的頁面

有時候可能還會針對不同的服務器環境（比如測試機、正式機）做出不同的構建，可以在后面加參數

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

多頁面應用會導出多個 html 文件，需要注意這些導出的 html 不要相沖突了。

當然，也可以用一些已經封裝好的工具，如 lila。

在構建好項目之后，就可以部署到服務器了。

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

自動化的，可以用一些工具部署到服務器，如 gulp、gulp-ssh，當然也可以用一些封裝的工具，如 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

另外，一般大型項目會使用持續集成 + shell 命令（如 rsync）部署。

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

持續集成工具用的比較多的：

jenkins

gitlab ci

jenkins 是通用型的工具，可以與 github、bitbucket、gitlab 等代碼托管服務配合使用，優點是功能強大、插件多、社區活躍，但缺點是配置復雜、使用難度較高。

gitlab ci 是 gitlab 內部自帶的持續集成功能，優點是使用簡單、配置簡單，但缺點是不及 jenkins 功能強大、綁定 gitlab 才能使用。

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

stages:
  - install
  - test
  - build
  - deploy

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

# 運行測試用例
test:
  stage: test
  only:
    - dev
    - master
  script:
    - npm run test

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

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

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

npm install

npm run test

npm run clean

npm run build

npm run deploy

最終完成部署。如果中間某個命令失敗了，將停止接下的命令的運行，并將錯誤報告給你。

這些操作都在遠程機器上完成。

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

到這里為止，基本上完成了一個項目的搭建、編寫、構建。

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

當用戶在用線上的程序時，怎么知道有沒有出 bug；如果出 bug 了，報的是什么錯；如果是 js 報錯，怎么知道是那一行運行出了錯？

所以，在程序運行時捕捉 js 腳本錯誤，并上報到服務器，是非常有必要的。

這里就要用到 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); // 上報到服務器
};

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

參考：

前端如何高效的與后端協作開發

細說 js 壓縮、sourcemap、通過 sourcemap 查找原始報錯信息

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

作者：深予之 (@senntyou)

版權聲明：自由轉載-非商用-非衍生-保持署名（創意共享3.0許可證）