Webpack 服務器端代碼打包

xiaowugui666 發布于2019-08-22 11:10 / 2817人閱讀

摘要：環境變量之前我們在項目里會經常使用但這個變量對于打包是有影響的在的時候是有優化的所以我們將改用其他的環境變量來區別像這樣始終為而我們實際開發產品環境用變量來使用由于該項目是一個接口服務項目所以這樣進行命名可以改成任意的你開心就好動態配置打包

環境變量

之前,我們在項目里會經常使用 process.env.NODE_ENV, 但這個變量對于 webpack打包是有影響的, 在 production 的時候是有優化的.

所以, 我們將改用其他的環境變量來區別:

new webpack.DefinePlugin({
  "process.env.NODE_ENV": ""production"",
  "process.env.API_ENV": `"${process.env.API_ENV || "development"}"`
})

像這樣, NODE_ENV 始終為 production.

而我們實際開發/產品環境, 用 process.env.API_ENV 變量來使用(由于該項目是一個 koa 接口服務項目, 所以這樣進行命名, 可以改成任意的, 你開心就好).

動態配置打包 注意

我們以前在 node.js 后端項目中, 動態配置加載一般是這樣寫:

const ENV = process.env.NODE_ENV || "development";
// eslint-disable-next-line import/no-dynamic-require
const options = require(`./_${ENV}`);

module.exports = options;

為了提高閱讀性, 和可能存在ENV的復用, 我們會多帶帶定義一個變量.

在 webpack 打包的項目中直接這樣做的話, 會產生一個問題. 比如我現在有多個配置:

_develpment.js

_test.js

_production.js

_staging.js

即便我傳入的當前環境為 development, 依然所有的配置文件會被全部打包進來(只是永遠不會被執行). 那么這樣的話, 就存在敏感信息泄露的風險.

正確的姿勢應該是這樣的:

config/index.js

// eslint-disable-next-line import/no-dynamic-require
const options = require(`./_${process.env.API_ENV || "development"}`);

module.exports = options;

模塊化打包

比如, 我在項目中有很多個模塊, 處于負載均衡的需求, 或者是對于客戶定制模塊化產品的需求, 我們需要分模塊進行打包, 避免其他模塊(永遠不會被執行的)被打包進 webpack bundle.

// config/_development.js
exports.enabledModules = ["user", "demo"]; 
// 可能 src 目錄下 還有其他模塊目錄, 如 "manage" 等

在服務端加載的時候, 是這樣子的:

// src/server.js
// 動態加載啟用的模塊
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 其實對于服務器端代碼打包并不友好, 可能會導致打包的失敗, 用 babel-minify-webpack-plugin 插件來替代.

配合 source-map-support 插件來支持源碼的問題定位.

示例項目源碼： https://github.com/AirDwing/w...

原文鏈接： https://leader.js.cool/#/expe...

云服務器 GPU云服務器 Webpack打包分塊移動端js圖片打包 html代碼打包阿里云服務器代碼打包

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/91897.html

9102年：手寫一個React腳手架【優化極致版】

摘要：馬上要出了，完全手寫一個優化后的腳手架是不可或缺的技能。每個依賴項隨即被處理，最后輸出到稱之為的文件中，我們將在下一章節詳細討論這個過程。的事件流機制保證了插件的有序性，使得整個系統擴展性很好。 webpack馬上要出5了，完全手寫一個優化后的腳手架是不可或缺的技能。本文書寫時間 2019年5月9日 , webpack版本 4.30.0最新版本本人所有代碼均手寫，親自試驗過可...

Kylin_Mountain 2019-08-02 16:17 評論0 收藏0
9102年：手寫一個React腳手架【優化極致版】

摘要：馬上要出了，完全手寫一個優化后的腳手架是不可或缺的技能。每個依賴項隨即被處理，最后輸出到稱之為的文件中，我們將在下一章節詳細討論這個過程。的事件流機制保證了插件的有序性，使得整個系統擴展性很好。 webpack馬上要出5了，完全手寫一個優化后的腳手架是不可或缺的技能。本文書寫時間 2019年5月9日 , webpack版本 4.30.0最新版本本人所有代碼均手寫，親自試驗過可...

whatsns 2019-08-30 10:49 評論0 收藏0
9102年：手寫一個React腳手架【優化極致版】

摘要：馬上要出了，完全手寫一個優化后的腳手架是不可或缺的技能。每個依賴項隨即被處理，最后輸出到稱之為的文件中，我們將在下一章節詳細討論這個過程。的事件流機制保證了插件的有序性，使得整個系統擴展性很好。 webpack馬上要出5了，完全手寫一個優化后的腳手架是不可或缺的技能。本文書寫時間 2019年5月9日 , webpack版本 4.30.0最新版本本人所有代碼均手寫，親自試驗過可...

bingo 2019-08-26 18:26 評論0 收藏0
基于 Webpack 4 多入口生成模板用于服務端渲染的方案及實戰

摘要：原作者原鏈接基于多入口生成模板用于服務端渲染的方案及實戰法律聲明警告本作品遵循署名非商業性使用禁止演繹未本地化版本協議發布。這是什么背景現代化的前端項目中很多都使用了客戶端渲染的單頁面應用。原作者：@LinuxerPHL原鏈接：基于 Webpack 4 多入口生成模板用于服務端渲染的方案及實戰法律聲明警告：本作品遵循署名-非商業性使用-禁止演繹3.0 未本地化版本（CC BY-...

big_cat 2019-08-26 10:37 評論0 收藏0
基于 Webpack 4 多入口生成模板用于服務端渲染的方案及實戰

摘要：原作者原博文地址基于多入口生成模板用于服務端渲染的方案及實戰法律聲明警告本作品遵循署名非商業性使用禁止演繹未本地化版本協議發布。這是什么背景現代化的前端項目中很多都使用了客戶端渲染的單頁面應用。原作者：@LinuxerPHL原博文地址: 基于 Webpack 4 多入口生成模板用于服務端渲染的方案及實戰法律聲明警告：本作品遵循署名-非商業性使用-禁止演繹3.0 未本地化版本（...

Lavender 2019-08-26 10:37 評論0 收藏0