摘要:環(huán)境變量之前我們在項目里會經(jīng)常使用但這個變量對于打包是有影響的在的時候是有優(yōu)化的所以我們將改用其他的環(huán)境變量來區(qū)別像這樣始終為而我們實際開發(fā)產(chǎn)品環(huán)境用變量來使用由于該項目是一個接口服務(wù)項目所以這樣進行命名可以改成任意的你開心就好動態(tài)配置打包
環(huán)境變量
之前,我們在項目里會經(jīng)常使用 process.env.NODE_ENV, 但這個變量對于 webpack打包是有影響的, 在 production 的時候是有優(yōu)化的.
所以, 我們將改用其他的環(huán)境變量來區(qū)別:
new webpack.DefinePlugin({ "process.env.NODE_ENV": ""production"", "process.env.API_ENV": `"${process.env.API_ENV || "development"}"` })
像這樣, NODE_ENV 始終為 production.
而我們實際開發(fā)/產(chǎn)品環(huán)境, 用 process.env.API_ENV 變量來使用(由于該項目是一個 koa 接口服務(wù)項目, 所以這樣進行命名, 可以改成任意的, 你開心就好).
動態(tài)配置打包 注意我們以前在 node.js 后端項目中, 動態(tài)配置加載一般是這樣寫:
const ENV = process.env.NODE_ENV || "development"; // eslint-disable-next-line import/no-dynamic-require const options = require(`./_${ENV}`); module.exports = options;
為了提高閱讀性, 和可能存在ENV的復(fù)用, 我們會多帶帶定義一個變量.
在 webpack 打包的項目中直接這樣做的話, 會產(chǎn)生一個問題. 比如我現(xiàn)在有多個配置:
_develpment.js
_test.js
_production.js
_staging.js
即便我傳入的當(dāng)前環(huán)境為 development, 依然所有的配置文件會被全部打包進來(只是永遠不會被執(zhí)行). 那么這樣的話, 就存在敏感信息泄露的風(fēng)險.
正確的姿勢應(yīng)該是這樣的:
config/index.js// eslint-disable-next-line import/no-dynamic-require const options = require(`./_${process.env.API_ENV || "development"}`); module.exports = options;模塊化打包
比如, 我在項目中有很多個模塊, 處于負載均衡的需求, 或者是對于客戶定制模塊化產(chǎn)品的需求, 我們需要分模塊進行打包, 避免其他模塊(永遠不會被執(zhí)行的)被打包進 webpack bundle.
// config/_development.js exports.enabledModules = ["user", "demo"]; // 可能 src 目錄下 還有其他模塊目錄, 如 "manage" 等
在服務(wù)端加載的時候, 是這樣子的:
// src/server.js // 動態(tài)加載啟用的模塊 enabledModules.forEach((mod) => { /* eslint-disable global-require,import/no-dynamic-require */ const routes = require(`./${mod}/route`); routes.middleware() |> app.use; });
那么就需要 ContextReplacementPlugin 插件來支持了.
new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(${enabledModules.join("|")})/.*$`))進階使用
比如,src目錄下除了各個模塊的目錄, 還有一些通用方法類,鉤子的目錄, 如: lib 和 hook. 這兩個目錄是可能被其他子模塊共同引用的. 在插件正則中修改:
new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(lib|hook|${enabledModules.join("|")})/.*$`))壓縮代碼, 并添加 source-map 支持
Uglifyjs 或 Uglify-es 其實對于服務(wù)器端代碼打包并不友好, 可能會導(dǎo)致打包的失敗, 用 babel-minify-webpack-plugin 插件來替代.
配合 source-map-support 插件來支持源碼的問題定位.
示例項目源碼: https://github.com/AirDwing/w...
原文鏈接: https://leader.js.cool/#/expe...
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/91897.html
摘要:馬上要出了,完全手寫一個優(yōu)化后的腳手架是不可或缺的技能。每個依賴項隨即被處理,最后輸出到稱之為的文件中,我們將在下一章節(jié)詳細討論這個過程。的事件流機制保證了插件的有序性,使得整個系統(tǒng)擴展性很好。 webpack馬上要出5了,完全手寫一個優(yōu)化后的腳手架是不可或缺的技能。 本文書寫時間 2019年5月9日 , webpack版本 4.30.0最新版本 本人所有代碼均手寫,親自試驗過可...
摘要:馬上要出了,完全手寫一個優(yōu)化后的腳手架是不可或缺的技能。每個依賴項隨即被處理,最后輸出到稱之為的文件中,我們將在下一章節(jié)詳細討論這個過程。的事件流機制保證了插件的有序性,使得整個系統(tǒng)擴展性很好。 webpack馬上要出5了,完全手寫一個優(yōu)化后的腳手架是不可或缺的技能。 本文書寫時間 2019年5月9日 , webpack版本 4.30.0最新版本 本人所有代碼均手寫,親自試驗過可...
摘要:馬上要出了,完全手寫一個優(yōu)化后的腳手架是不可或缺的技能。每個依賴項隨即被處理,最后輸出到稱之為的文件中,我們將在下一章節(jié)詳細討論這個過程。的事件流機制保證了插件的有序性,使得整個系統(tǒng)擴展性很好。 webpack馬上要出5了,完全手寫一個優(yōu)化后的腳手架是不可或缺的技能。 本文書寫時間 2019年5月9日 , webpack版本 4.30.0最新版本 本人所有代碼均手寫,親自試驗過可...
摘要:原作者原鏈接基于多入口生成模板用于服務(wù)端渲染的方案及實戰(zhàn)法律聲明警告本作品遵循署名非商業(yè)性使用禁止演繹未本地化版本協(xié)議發(fā)布。這是什么背景現(xiàn)代化的前端項目中很多都使用了客戶端渲染的單頁面應(yīng)用。 原作者:@LinuxerPHL原鏈接:基于 Webpack 4 多入口生成模板用于服務(wù)端渲染的方案及實戰(zhàn) 法律聲明 警告:本作品遵循 署名-非商業(yè)性使用-禁止演繹3.0 未本地化版本(CC BY-...
摘要:原作者原博文地址基于多入口生成模板用于服務(wù)端渲染的方案及實戰(zhàn)法律聲明警告本作品遵循署名非商業(yè)性使用禁止演繹未本地化版本協(xié)議發(fā)布。這是什么背景現(xiàn)代化的前端項目中很多都使用了客戶端渲染的單頁面應(yīng)用。 原作者:@LinuxerPHL原博文地址: 基于 Webpack 4 多入口生成模板用于服務(wù)端渲染的方案及實戰(zhàn) 法律聲明 警告:本作品遵循 署名-非商業(yè)性使用-禁止演繹3.0 未本地化版本(...
閱讀 1943·2021-11-25 09:43
閱讀 2175·2021-11-19 09:40
閱讀 3459·2021-11-18 13:12
閱讀 1770·2021-09-29 09:35
閱讀 699·2021-08-24 10:00
閱讀 2536·2019-08-30 15:55
閱讀 1740·2019-08-30 12:56
閱讀 1847·2019-08-28 17:59