前言
GitHub 完整項目地址
最近接了一個公司官網的項目,需要 SEO 友好,所以不能使用前端框架,前端框架自帶的腳手架工具自然也幫不上啥忙。只好自己使用 webpack4 + ejs + express ,從頭搭建一個多頁應用的項目架構。搭建過程中,遇到許多坑,然而網上的相關參考也是非常少,所以寫個博客記錄一下搭建過程以及注意事項。
項目地址
GitHub
明確需求
在動手開發之前,我們需要先明確這個項目的定位——公司官網,一般來説,官網不會涉及大量的數據交互,比較偏向於數據展示。所以不用前端框架,jquery 即可滿足需求。但是考慮到 SEO 所以需要用到服務端渲染,就要使用模板語言(ejs),配合 node 來完成。
根據以上信息,我們就可以確定打包腳本的基本功能,先來簡單列個清單:
- 需要
webpack來打包多頁應用,且不需要每次新增一個視圖文件都添加一個HTMLWebpackPlugin和重啓 server ,能做到 webpack 配置和文件名解耦,儘量的自動化。 - 需要使用
ejs模板語言編寫,能夠插入變量和外部includes文件,最後運行 build 命令的時候能將通用模板文件(<meta>/<title>/<header>/<footer>等)自動插入每個視圖文件對應位置。 - 需要用到服務端渲染,所以開發環境要脱離 webpack 集成的
webpack-dev-server,能使用自己編寫的 node 代碼啓動服務。 - 擁有完善的
overlay功能,可以像webpack-dev-server那樣集成漂亮的 overlay 屏幕報錯。 - 能監聽文件變化,自動打包和重啓服務,最好能做到熱更新
開始構建
先建立一個空項目,由於需要自己編寫服務端代碼,所以我們需要多建一個 /server 文件夾,用來存放 express 的代碼,搭建完成後,我們的項目結構看起來是這樣。
除此以外,我們需要初始化一些通用配置文件,包括:
.babelrcbabel 配置文件.gitignoregit 忽略文件.editorConfig編輯器配置文件.eslintrc.jseslint 配置文件README.md文件package.json文件
大的框架出來以後,我們開始編寫工程代碼。
打包腳本
首先是編寫打包腳本,在/build文件夾裏新建幾個文件
webpack.base.config.js,用來存放生產環境和開發環境通用的 webpack 配置webpack.dev.config.js用來存放開發環境的打包配置webpack.prod.config.js用來存放生產環境的打包配置config.json用來存放一些配置常量,例如端口名,路徑名之類。
一般來説,webpack.base.config 文件裏,放一些開發生產環境通用的配置,例如 output、entry 以及一些 loader, 例如編譯ES6語法的 babel-loader、打包文件的 file-loader 等。常用的 loader 的使用方式我們可以查看文檔 webpack loaders,需要注意的是,這邊有個非常重要的 loader ———— ejs-html-loader
一般來説,我們使用 html-loader 來對.html結尾的視圖文件做處理,然後扔給 html-webpack-plugin生成對應的文件,但是 html-loader 無法處理 ejs 模板語法中的 <% include ... %> 語法,會報錯。然而在多頁應用裏,這個 include 的功能是必須的,不然每個視圖文件裏都要手動去寫一份 header/footer 是什麼感覺。。。所以我們需要再多配置一份 ejs-html-loader:
// webpack.base.config.js 部分代碼
module: {
rules: [
...
{
test: /\.ejs$/,
use: [
{
loader: 'html-loader', // 使用 html-loader 處理圖片資源的引用
options: {
attrs: ['img:src', 'img:data-src']
}
},
{
loader: 'ejs-html-loader', // 使用 ejs-html-loader 處理 .ejs 文件的 includes 語法
options: {
production: process.env.ENV === 'production'
}
}
]
}
...
]
}
第一個坑繞過之後,第二個:entry 入口要怎麼寫?
記得之前公司的一個老項目,五十幾個頁面,五十幾個 entry 和 new HTMLwebpackPlugin() 一個文件展開來可以繞地球一圈。。。這邊為了避免這種慘狀,寫一個方法,返回一個 entry 數組。
可以使用 glob 來處理這些文件,獲取文件名,當然同樣也可以使用原生 node 來實現。只要保證 JavaScript 文件名和視圖文件名相同即可,比如,首頁的視圖文件名是 home.ejs,那麼對應的腳本文件名就要用同樣的名字 home.js 來命名,webpack 打包的時候會找到腳本文件入口,通過映射關係生成對應視圖文件:
// webpack.base.config.js 部分代碼
const Webpack = require('Webpack')
const glob = require('glob')
const { resolve } = require('path')
// webpack 入口文件
const entry = ((filepathList) => {
let entry = {}
filepathList.forEach(filepath => {
const list = filepath.split(/[\/|\/\/|\\|\\\\]/g) // 斜槓分割文件目錄
const key = list[list.length - 1].replace(/\.js/g, '') // 拿到文件的 filename
// 如果是開發環境,才需要引入 hot module
entry[key] = process.env.NODE_ENV === 'development' ? [filepath, 'webpack-hot-middleware/client?reload=true'] : filepath
})
return entry
})(glob.sync(resolve(__dirname, '../src/js/*.js')))
module.exports = {
entry,
...
}
HTMLWebpackPlugin 的配置也同理:
// webpack.base.config.js 部分代碼
...
plugins: [
// 打包文件
...glob.sync(resolve(__dirname, '../src/tpls/*.ejs')).map((filepath, i) => {
const tempList = filepath.split(/[\/|\/\/|\\|\\\\]/g) // 斜槓分割文件目錄
const filename = `views/${tempList[tempList.length - 1]}` // 拿到文件的 filename
const template = filepath // 指定模板地址為對應的 ejs 視圖文件路徑
const fileChunk = filename.split('.')[0].split(/[\/|\/\/|\\|\\\\]/g).pop() // 獲取到對應視圖文件的 chunkname
const chunks = ['manifest', 'vendors', fileChunk] // 組裝 chunks 數組
return new HtmlWebpackPlugin({ filename, template, chunks }) // 返回 HtmlWebpackPlugin 實例
})
]
...
編寫好 webpack.base.config.js 文件,根據自己項目需求編寫好 webpack.dev.config.js 和 webpack.prod.config.js,使用 webpack-merge 將基礎配置和對應環境下的配置合併。
webpack 其他的一些細節配置大家可以參考 webpack 中文網址
服務端
打包腳本編寫完成,我們開始編寫服務,我們使用 express 來搭建服務。(由於是工程架構演示,所以這個服務暫不涉及任何的數據庫的增刪改查,只是包含基本的路由跳轉)
server 簡單的結構如下:
服務端啓動文件
bin/server.js 啓動文件,作為服務的入口,需要同時啓動本地服務和 webpack 的開發時編譯。一般項目 webpack-dev-server 是寫在 package.json 裏的,當你運行 npm run dev 的時候,就在使用 webpack-dev-server 啓動開發服務,這個 webpack-dev-server 功能十分強大,不僅能一鍵啓動本地服務,還可以監聽模塊,實時編譯。這邊我們使用 express + webpack-dev-middleware 也可以達到同樣的功能。
webpack-dev-middleware 可以理解為一個抽離出來的 webpack-dev-server,只是沒有啓動本地服務的功能,以及使用方式上略有改變。它相比於 webpack-dev-server 的靈活性在於,它以一箇中間件的形式存在,允許開發者編寫自己的服務來使用它。
其實 webpack-dev-server 的內部實現機制也是藉助於 webpack-dev-middleware 和 express 有興趣的朋友可以去看一下。
以下是服務入口文件的部分代碼
// server/bin/server.js 文件代碼
const path = require('path')
const express = require('express')
const webpack = require('webpack')
const webpackDevMiddleware = require('webpack-dev-middleware')
const webpackHotMiddleware = require('webpack-hot-middleware')
const { routerFactory } = require('../routes')
const isDev = process.env.NODE_ENV === 'development'
let app = express()
let webpackConfig = require('../../build/webpack.dev.config')
let compiler = webpack(webpackConfig)
// 開發環境下才需要啓用實時編譯和熱更新
if (isDev) {
// 用 webpack-dev-middleware 啓動 webpack 編譯
app.use(webpackDevMiddleware(compiler, {
publicPath: webpackConfig.output.publicPath,
overlay: true,
hot: true
}))
// 使用 webpack-hot-middleware 支持熱更新
app.use(webpackHotMiddleware(compiler, {
publicPath: webpackConfig.output.publicPath,
noInfo: true
}))
}
// 添加靜態資源攔截轉發
app.use(webpackConfig.output.publicPath, express.static(path.resolve(__dirname, isDev ? '../../src' : '../../dist')))
// 構造路由
routerFactory(app)
// 錯誤處理
app.use((err, req, res, next) => {
res.status(err.status || 500)
res.send(err.stack || 'Service Error')
})
app.listen(port, () => console.log(`development is listening on port 8888`))
服務端路由
路由的跳轉方式,屬於整個工程中非常重要的一步。不知道閲讀文章的朋友有沒有疑問,本地的視圖文件是 .ejs 後綴結尾的文件,瀏覽器只能識別 .html 後綴文件,這塊視圖數據的渲染是怎麼做的? webpack-dev-middleware 打包出來的資源都是存在內存中的,存儲在內存中的資源文件,服務端要怎麼獲取?
先來看具體的路由代碼,此處以首頁路由作為演示
// server/routs/home.js 文件
const ejs = require('ejs')
const { getTemplate } = require('../common/utils')
const homeRoute = function (app) {
app.get('/', async (req, res, next) => {
try {
const template = await getTemplate('index.ejs') // 獲取 ejs 模板文件
let html = ejs.render(template, { title: '首頁' })
res.send(html)
} catch (e) {
next(e)
}
})
app.get('/home', async (req, res, next) => {
try {
const template = await getTemplate('index.ejs') // 獲取 ejs 模板文件
let html = ejs.render(template, { title: '首頁' })
res.send(html)
} catch (e) {
next(e)
}
})
}
module.exports = homeRoute
可以看到關鍵點就在 getTemplate 這個方法,我們看看這個 getTemplate 做了咩
// server/common/utils.js 文件
const axios = require('axios')
const CONFIG = require('../../build/config')
function getTemplate (filename) {
return new Promise((resolve, reject) => {
axios.get(`http://localhost:8888/public/views/${filename}`) // 注意這個 'public' 公共資源前綴非常重要
.then(res => {
resolve(res.data)
})
.catch(reject)
})
}
module.exports = {
getTemplate
}
從上面代碼可以看到,路由中的做的非常重要的事情,就是直接用對應視圖的 ejs 文件名,去請求自身服務,從而獲取到存在 webpack 緩存中的資源和數據。
通過這種方式拿到模板字符串後,ejs 引擎會用數據渲染對應變量,最終以 html 字符串的形式返回到瀏覽器進行渲染。
本地服務會以一個 publicPath 路徑前綴來標記靜態資源請求,如果服務接受到的請求是帶有 publicPath 前綴,就會被 /bin/server.js 中的靜態資源中間件攔截到,映射到對應資源目錄,返回靜態資源,而這個 publicPath 就是 webpack 配置中的 output.publicPath
關於 webpack 的打包時緩存,我之前翻了很多地方都沒有找到很好的文檔和操作工具,這邊給大家推薦兩個鏈接
- Webpack Custom File Systems (webpack 自定義文件系統官方説明)
- memory-fs(獲取 webpack 編譯到內存中的數據)
客户端
完成了服務端渲染、webpack 構建配置後,算是搞定了 80% 的工作量,還有一些小細節需要注意,不然服務啓動起來還是會報錯。
webpack 編譯時的坑
這個坑就埋在客户端的視圖文件裏,先來看看坑是什麼:當我們使用 ejs 語法(<%= title %>)這種語法的時候,webpack 編譯就會報錯,説是 title is undefined
要解決這個問題,需要首先明白 webpack 編譯時的運行機制,它做了什麼。我們知道,webpack 內部模板機制就是基於的 ejs,所以在我們服務端渲染之前,也就是 webpack 的編譯階段,已經執行過了一次 ejs.render 了,這個時候,在 webpack 的配置文件裏,我們是沒有傳遞過 title 這個變量的,所以編譯會報錯。那麼要怎麼寫才能識別呢?答案就在 ejs 的官方文檔
從官網的介紹上可以看出,當我們使用 <%% 打頭的時候,會被轉義成 <% 字符串,類似於 html 標籤的轉義,這樣才能避免 webpack 中自帶的 ejs 的錯誤識別,生成正確的 ejs 文件。所以以變量為例,在代碼中我們需要這樣寫: <%%= title %> 這樣,webpack 才能順利編譯完成,將 compiler 繼續傳遞到 ejs-html-loader 這裏
使用 html-loader 識別圖片資源
如果瞭解 html-loader 的朋友就知道,在項目中,我們之所以能夠在 html 中方便的寫 <img src="../static/imgs/XXX.png"> 這種圖片格式,還能被 webpack 正確識別,離不開 html-loader 裏的 attrs 配置項,
但是在 ejs-html-loader 裏,沒有提供這種方便的功能,所以我們依舊要使用 html-loader 來對 html 中的圖片引用做處理,這邊需要注意 loader 的配置順序
// webpack.base.config.js 部分代碼
module: {
rules: [
...
{
test: /\.ejs$/,
use: [
{
loader: 'html-loader', // 使用 html-loader 處理圖片資源的引用
options: {
attrs: ['img:src', 'img:data-src']
}
},
{
loader: 'ejs-html-loader', // 使用 ejs-html-loader 處理 .ejs 文件的 includes 語法
options: {
production: process.env.ENV === 'production'
}
}
]
}
...
]
}
配置熱更新
接下來是配置熱更新,使用 webpack-dev-middleware 時的熱更新配置方式和 webpack-dev-server 略有不同,但是 webpack-dev-middleware 稍微簡單一點。webpack 打包多頁應用配置熱更新,一共四步:
- 在
entry入口裏多寫一個webpack-hot-middleware/client?reload=true的入口文件
// webpack.base.config.js 部分代碼
// webpack 入口文件
const entry = ((filepathList) => {
let entry = {}
filepathList.forEach(filepath => {
...
// 如果是開發環境,才需要引入 hot module
entry[key] = process.env.NODE_ENV === 'development' ? [filepath, 'webpack-hot-middleware/client?reload=true'] : filepath
...
})
return entry
})(...)
module.exports = {
entry,
...
}
-
在 webpack 的
plugins裏多寫三個 plugin:// webpack.dev.config.js 文件部分代碼 plugins: [ ... // OccurrenceOrderPlugin is needed for webpack 1.x only new Webpack.optimize.OccurrenceOrderPlugin(), new Webpack.HotModuleReplacementPlugin(), // Use NoErrorsPlugin for webpack 1.x new Webpack.NoEmitOnErrorsPlugin() ... ] -
在
bin/server.js服務入口中引入webpack-hot-middleware, 並將webpack-dev-server打包完成的compiler用webpack-hot-middleware包裝起來:// server/bin/server.js 文件 let compiler = webpack(webpackConfig) // 用 webpack-dev-middleware 啓動 webpack 編譯 app.use(webpackDevMiddleware(compiler, { publicPath: webpackConfig.output.publicPath, overlay: true, hot: true })) // 使用 webpack-hot-middleware 支持熱更新 app.use(webpackHotMiddleware(compiler, { publicPath: webpackConfig.output.publicPath, reload: true, noInfo: true })) -
在視圖對應的 js 文件里加一段代碼:
// src/js/index.js 文件 if (module.hot) { module.hot.accept() }
關於 webpack-hot-middleware 的更多配置細節,請看文檔
這邊需要注意的是:
1. 光是這麼寫的話,webpack hot module 只能支持 JS 部分的修改,如果需要支持樣式文件( css / less / sass ... )的 hot reload ,就不能使用 extract-text-webpack-plugin 將樣式文件剝離出去,否則無法監聽修改、實時刷新。
2. webpack hot module 原生是不支持 html 的熱替換的,但是很多開發者對於這塊的需求比較大,於是我找了一個相對比較簡單的方法,來支持視圖文件的熱更新
需要在原有的代碼做一點修改,先來看代碼:
// src/js/index.js 文件
import axios from 'axios'
// styles
import 'less/index.less'
const isDev = process.env.NODE_ENV === 'development'
// 在開發環境下,使用 raw-loader 引入 ejs 模板文件,強制 webpack 將其視為需要熱更新的一部分 bundle
if (isDev) {
require('raw-loader!../tpls/index.ejs')
}
...
if (module.hot) {
module.hot.accept()
/**
* 監聽 hot module 完成事件,重新從服務端獲取模板,替換掉原來的 document
* 這種熱更新方式需要注意:
* 1. 如果你在元素上之前綁定了事件,那麼熱更新之後,這些事件可能會失效
* 2. 如果事件在模塊卸載之前未銷燬,可能會導致內存泄漏
*/
module.hot.dispose(() => {
const href = window.location.href
axios.get(href).then(res => {
const template = res.data
document.body.innerHTML = template
}).catch(e => {
console.error(e)
})
})
}
// webpack.dev.config.js
plugins: [
...
new webpack.DefinePlugin({
'process.env.NODE_ENV': JSON.stringify('development')
})
...
]
// webpack.prod.config.js
plugins: [
...
new webpack.DefinePlugin({
'process.env.NODE_ENV': JSON.stringify('production')
})
...
]
OK,如你所願,現在視圖文件也支持熱更新啦。😃😃
webpack-hot-middleware 默認繼承了 overlay,所以當熱更新配置完成以後,overlay 報錯功能也能正常使用了
package.json 啓動腳本
最後來看一下 package.json 裏的啓動腳本,這邊沒啥難度,就直接上代碼了
"scripts": {
"clear": "rimraf dist",
"server": "cross-env NODE_ENV=production node ./server/bin/server.js",
"dev": "cross-env NODE_ENV=development nodemon --watch server ./server/bin/server.js",
"build": "npm run clear && cross-env NODE_ENV=production webpack --env production --config ./build/webpack.prod.config.js",
"test": "echo \"Error: no test specified\" && exit 1"
}
當客户端代碼變動時 webpack 會自動幫我們編譯重啓,但是服務端的代碼變動卻不會實時刷新,這時需要用到 nodemon,設置好監聽目錄以後,服務端的任何代碼修改就能被 nodemon 監聽,服務自動重啓,非常方便。
這邊也有一個小細節需要注意,nodemon --watch 最好指定監聽服務端文件夾,因為畢竟只有服務端的代碼修改才需要重啓服務,不然默認監聽整個根目錄,寫個樣式都能重啓服務,簡直要把人煩死。
總結
項目整體搭完後再回頭看,還是有不少需要注意和值得學習的地方。雖然踩了不少坑,但也對其中的一些原理有了更深入的瞭解。
得益於前端腳手架工具,讓我們能在大部分項目中一鍵生成項目的基礎配置,免去了很多工程搭建的煩惱,但這種方便在造福了開發者的同時,卻也弱化了前端工程師的工程架構能力。現實中總有一些腳手架工具沒辦法的觸及到的業務場景,這時就需要開發者主動尋求解決方案,甚至自己動手構建工程,以獲得開發的最佳靈活性。
完整項目地址可以查看我的 GitHub,喜歡的話給個 Star⭐️ ,多謝多謝~😃😃