從 0 到 1 再到 100, 搭建、編寫、構建一個前端項目

時間  2019-11-08
標籤 再到 搭建 編寫 構建 一個 前端 項目 简体版
原文   原文鏈接

從 0 到 1 再到 100, 搭建、編寫、構建一個前端項目

1. 選擇現成的項目模板仍是本身搭建項目骨架

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

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

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

社區比較好的項目模板：vue

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

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

1.1 使用 git 直接克隆到本地

這是一種真正意義上的模板，能夠直接到模板項目的 github 主頁，就能看到整個骨架，好比 react-boilerplate、ant-design-pro、vue-element-admin、react-starter-kit。jquery

以 react-boilerplate 爲例：webpack

克隆到本地：git

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

切換到目錄下：es6

cd <你的項目名字>

通常來講，接下來運行 npm run install 安裝項目的依賴後，就能夠運行；有些模板可能有內置的初始化命令，好比 react-boilerplate：

npm run setup

啓動應用：

npm start

這時，就能夠在瀏覽器中預覽應用了。

1.2 使用命令行建立

這種方式須要安裝相應的命令，而後由命令來建立項目。

以 create-react-app 爲例：

安裝命令：

npm install -g create-react-app

建立項目：

create-react-app my-app

運行應用：

cd my-app
npm start

1.3 本身搭建項目骨架

若是你須要定製化，能夠選擇本身搭建項目的骨架，但這須要開發者對構建工具如 webpack、npm、node 及其生態等有至關的瞭解與應用，才能完美的把控整個項目。

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

2. 選擇合適的規範來寫代碼

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

  • iife: js 原生支持，但通常不會直接使用這種規範寫代碼
  • amd: requirejs 定義的加載規範，但隨着構建工具的出現，便通常不會用這種規範寫代碼
  • commonjs: node 的模塊加載規範，通常會用這種規範寫 node 程序
  • es6: ECMAScript2015 定義的模塊加載規範，須要轉碼後瀏覽器才能運行

這裏推薦使用 es6 的模塊化規範來寫代碼，而後用工具轉換成 es5 的代碼，而且 es6 的代碼可使用 Tree shaking 功能。

參考：

3. 選擇合適的構建工具

對於前端項目來講，構建工具通常都選用 webpack，webpack 提供了強大的功能和配置化運行。若是你不喜歡複雜的配置，能夠嘗試 parcel。

參考：

4. 肯定是單頁面應用（SPA）仍是多頁面應用

由於單頁面應用與多頁面應用在構建的方式上有很大的不一樣，因此須要從項目一開始就肯定，使用哪一種模式來構建項目。

4.1 多頁面應用

傳統多頁面是由後端控制一個 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。

4.2 單頁面應用

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

通常單頁面應用都有如下幾個特色：

  • 本地路由，由 js 定義路由、根據路由渲染頁面、控制頁面的跳轉
  • 全部文件只會加載一次，最大限度重用文件，而且極大提高加載速度
  • 按需加載，只有真正使用到頁面的時候，才加載相應的文件

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

參考：

5. 選擇合適的前端框架與 UI 庫

通常在搭建項目的時候就須要定下前端框架與 UI 庫，由於若是後期想更換前端框架和 UI 庫，代價是很大的。

比較現代化的前端框架：

一些不錯的組合：

參考：

6. 定好目錄結構

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

一個好的目錄結構應當具備如下的一些特色：

  1. 解耦：代碼儘可能去耦合，這樣代碼邏輯清晰，也容易擴展
  2. 分塊：按照功能對代碼進行分塊、分組，並能快捷的添加分塊、分組
  3. 編輯器友好：須要更新功能時，能夠很快的定位到相關文件，而且這些文件應該是很靠近的，而不至於處處找文件

比較推薦的目錄結構：

多頁面應用

|-- 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/ 公共組件目錄   
|-- ...

參考：

7. 搭建一個好的腳手架

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

能夠查看 搭建本身的前端腳手架 瞭解一些基本的腳手架文件與工具。

好比：

|-- /                              項目根目錄
    |-- 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 持續集成服務

參考：

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

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

8. 使用版本控制系統管理源代碼（git）

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

比較經常使用的版本管理工具備 git、svn，如今通常都用 git。

通常開源的項目能夠託管到 http://github.com，私人的項目能夠託管到 https://gitee.com、https://coding.net/，而企業的項目則須要自建版本控制系統了。

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

因此，git + gitlab 是不錯的配合。

9. 編寫代碼

編寫代碼時，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" 改爲 "//precommit"
  • 若是你想自定 eslint 檢查代碼的規範，能夠修改 .eslintrc, .eslintrc.js 等配置文件
  • 若是你想自定 stylelint 檢查代碼的規範，能夠修改 .stylelintrc, .stylelintrc.js 等配置文件
  • 若是你想忽略某些文件不進行代碼檢查，能夠修改 .eslintignore, .stylelintignore 配置文件

參考：

10. 組件化

當項目擁有了必定量的代碼以後，就會發現，有些代碼是不少頁面共用的，因而把這些代碼提取出來，封裝成一個組件，供各個地方使用。

當擁有多個項目的時候，有些組件須要跨項目使用，一種方式是複製代碼到其餘項目中，但這種方式會致使組件代碼很難維護，因此，通常是用另外一種方式：組件化。

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

通常組件化會配合私有 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 庫、前端組件庫。

參考：

11. 測試

測試的目的在於能以最少的人力和時間發現潛在的各類錯誤和缺陷，這在項目更新、重構等的過程當中尤爲重要，由於每當更改一些代碼後，你並不知道這些代碼有沒有問題、會不會影響其餘的模塊。若是有了測試，運行一遍測試用例，就知道更改的代碼有沒有問題、會不會產生影響。

通常前端測試分如下幾種：

  1. 單元測試：模塊單元、函數單元、組件單元等的單元塊的測試
  2. 集成測試：接口依賴（ajax）、I/O 依賴、環境依賴（localStorage、IndexedDB）等的上下文的集成測試
  3. 樣式測試：對樣式的測試
  4. E2E 測試：端到端測試，也就是在實際生產環境測試整個應用

通常會用到下面的一些工具：

另外，能夠參考 聊聊前端開發的測試。

12. 構建

通常單頁面應用的構建會有 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。

13. 部署

在構建好項目以後，就能夠部署到服務器了。

傳統的方式，能夠用 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）部署。

14. 持續集成測試、構建、部署

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

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

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

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

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

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

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

15. 清理服務器上過時文件

如今前端的項目基本上都會用 webpack 打包代碼，而且文件名（html 文件除外）都是 hash 化的，若是須要清除過時的文件而又不想把服務器上文件所有刪掉而後從新構建、部署，可使用 sclean 來清除過時文件。

16. 收集前端錯誤反饋

當用戶在用線上的程序時，怎麼知道有沒有出 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 查找原始報錯信息 瞭解詳細信息。

參考：

後續

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

做者：深予之 (@senntyou)

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

原文地址：https://segmentfault.com/a/1190000017158444

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程