本文章轉載該文章，寫的很詳細，十分推薦！！
1. 選擇現成的項目模板還是自己搭建項目骨架？
搭建一個前端項目的方式有兩種：選擇現成的項目模板、自己搭建項目骨架。
選擇一個現成的項目模板是搭建一個項目最快的方式，模板已經把基本的骨架搭建好了，你只需要向里面填充具體的業務代碼，就可以通過內置的工具與命令構建代碼、部署到服務器等。
一般來說，一個現成的項目模板會預定義一定的項目結構、書寫方式，在編寫項目代碼時需要遵循相應的規范；也會內置必要的工具，比如..editorconfig、eslint、stylelint、prettier、husky、lint-staged 等；也會內置必要的命令(package.json | scripts)，比如本地開發： npm run dev、本地預覽: npm run start 、構建：npm run build、部署： npm run deploy等。
github上比較好的項目模板：
這些模板的使用又分為兩種：使用git直接clone到本地、使用命令行創建。
(使用現有的模板構建項目，可以跳過第2~7步)
1.1 使用 git 直接克隆到本地
這是一種真正意義上的模板，可以直接到模板項目的 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
這樣就可以在瀏覽器中國預覽應用了。
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 上。
這種方式的應用，項目里會有多個入口文件，搭建項目的時候就需要對這種多入口模式進行封裝。另外，也可以選擇一些封裝的多入口構建工具，如 lila。
4.2 單頁面應用
單頁面應用（single page application），就是只有一個頁面的應用，頁面的刷新和內部子頁面的跳轉完全由 js 來控制。
一般單頁面應用都有以下幾個特點：
-
本地路由，由
js定義路由、根據路由渲染頁面、控制頁面的跳轉 -
所有文件只會加載一次，最大限度重用文件，並且極大提升加載速度
-
按需加載，只有真正使用到頁面的時候，才加載相應的文件
這種方式的應用，項目里只有一個入口文件，便無需封裝。
參考：
5. 選擇合適的前端框架與 UI 庫
一般在搭建項目的時候就需要定下前端框架與 UI 庫，因為如果后期想更換前端框架和 UI 庫，代價是很大的。
比較現代化的前端框架：
一些不錯的組合：
-
react + ant-design、material-ui、Semantic-UI：
react的組合
6. 定好目錄結構
一個好的目錄結構對一個好的項目而言是非常必要的。
一個好的目錄結構應當具有以下的一些特點：
-
解耦：代碼盡量去耦合，這樣代碼邏輯清晰，也容易擴展
-
分塊：按照功能對代碼進行分塊、分組，並能快捷的添加分塊、分組
-
編輯器友好：需要更新功能時，可以很快的定位到相關文件，並且這些文件應該是很靠近的，而不至於到處找文件
比較推薦的目錄結構：
多頁面應用
單頁面應用
7. 搭建一個好的腳手架
搭建一個好的腳手架，能夠更好的編寫代碼、構建項目等。
-
.``editorconfig: 用這個文件來統一不同編輯器的一些配置，比如tab轉 2 個空格、自動插入空尾行、去掉行尾的空格等，http://editorconfig.org -
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 中：
-
如果你想禁用這個功能，可以把
scripts中"precommit"改成"//precommit" -
如果你想自定
eslint檢查代碼的規范，可以修改.eslintrc, .eslintrc.js等配置文件 -
如果你想自定
stylelint檢查代碼的規范，可以修改.stylelintrc, .stylelintrc.js等配置文件 -
如果你想忽略某些文件不進行代碼檢查，可以修改
.eslintignore, .stylelintignore配置文件
10. 組件化
當項目擁有了一定量的代碼之后，就會發現，有些代碼是很多頁面共用的，於是把這些代碼提取出來，封裝成一個組件，供各個地方使用。
當擁有多個項目的時候，有些組件需要跨項目使用，一種方式是復制代碼到其他項目中，但這種方式會導致組件代碼很難維護，所以，一般是用另一種方式：組件化。
組件化就是將組件獨立成一個項目，然后在其他項目中安裝這個組件，才能使用。
一般組件化會配合私有 npm 倉庫一起用。
在 project1 中安裝 component1， component2 組件：
11. 測試
測試的目的在於能以最少的人力和時間發現潛在的各種錯誤和缺陷，這在項目更新、重構等的過程中尤其重要，因為每當更改一些代碼后，你並不知道這些代碼有沒有問題、會不會影響其他的模塊。如果有了測試，運行一遍測試用例，就知道更改的代碼有沒有問題、會不會產生影響。
一般前端測試分以下幾種：
-
單元測試：模塊單元、函數單元、組件單元等的單元塊的測試
-
集成測試：接口依賴（ajax）、I/O 依賴、環境依賴（localStorage、IndexedDB）等的上下文的集成測試
-
樣式測試：對樣式的測試
-
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 配置文件：
在 package.json 的 scripts 配置好命令：
另外，一般大型項目會使用持續集成 + shell 命令（如 rsync）部署。
14. 持續集成測試、構建、部署
一般大型工程的的構建與測試都會花很長的時間，在本地做這些事情的話就不太實際，這就需要做持續集成測試、構建、部署了。
持續集成工具用的比較多的：
jenkins 是通用型的工具，可以與 github、bitbucket、gitlab 等代碼托管服務配合使用，優點是功能強大、插件多、社區活躍，但缺點是配置復雜、使用難度較高。
gitlab ci 是 gitlab 內部自帶的持續集成功能，優點是使用簡單、配置簡單，但缺點是不及 jenkins 功能強大、綁定 gitlab 才能使用。
以 gitlab 為例（任務定義在 .gitlab-ci.yml 中）：
以上配置表示只要在 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 了：
線上的 js 腳本都是壓縮過的，需要用 sourcemap 文件與 source-map 查看原始的報錯堆棧信息，可以參考 細說 js 壓縮、sourcemap、通過 sourcemap 查找原始報錯信息 了解詳細信息。