摘要:环境变量之前我们在项目里会经常使用但这个变量对于打包是有影响的在的时候是有优化的所以我们将改用其他的环境变量来区别像这样始终为而我们实际开发产品环境用变量来使用由于该项目是一个接口服务项目所以这样进行命名可以改成任意的你开心就好动态配置打包
环境变量
之前,我们在项目里会经常使用 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...
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/91897.html
摘要:马上要出了,完全手写一个优化后的脚手架是不可或缺的技能。每个依赖项随即被处理,最后输出到称之为的文件中,我们将在下一章节详细讨论这个过程。的事件流机制保证了插件的有序性,使得整个系统扩展性很好。 webpack马上要出5了,完全手写一个优化后的脚手架是不可或缺的技能。 本文书写时间 2019年5月9日 , webpack版本 4.30.0最新版本 本人所有代码均手写,亲自试验过可...
摘要:马上要出了,完全手写一个优化后的脚手架是不可或缺的技能。每个依赖项随即被处理,最后输出到称之为的文件中,我们将在下一章节详细讨论这个过程。的事件流机制保证了插件的有序性,使得整个系统扩展性很好。 webpack马上要出5了,完全手写一个优化后的脚手架是不可或缺的技能。 本文书写时间 2019年5月9日 , webpack版本 4.30.0最新版本 本人所有代码均手写,亲自试验过可...
摘要:马上要出了,完全手写一个优化后的脚手架是不可或缺的技能。每个依赖项随即被处理,最后输出到称之为的文件中,我们将在下一章节详细讨论这个过程。的事件流机制保证了插件的有序性,使得整个系统扩展性很好。 webpack马上要出5了,完全手写一个优化后的脚手架是不可或缺的技能。 本文书写时间 2019年5月9日 , webpack版本 4.30.0最新版本 本人所有代码均手写,亲自试验过可...
摘要:原作者原链接基于多入口生成模板用于服务端渲染的方案及实战法律声明警告本作品遵循署名非商业性使用禁止演绎未本地化版本协议发布。这是什么背景现代化的前端项目中很多都使用了客户端渲染的单页面应用。 原作者:@LinuxerPHL原链接:基于 Webpack 4 多入口生成模板用于服务端渲染的方案及实战 法律声明 警告:本作品遵循 署名-非商业性使用-禁止演绎3.0 未本地化版本(CC BY-...
摘要:原作者原博文地址基于多入口生成模板用于服务端渲染的方案及实战法律声明警告本作品遵循署名非商业性使用禁止演绎未本地化版本协议发布。这是什么背景现代化的前端项目中很多都使用了客户端渲染的单页面应用。 原作者:@LinuxerPHL原博文地址: 基于 Webpack 4 多入口生成模板用于服务端渲染的方案及实战 法律声明 警告:本作品遵循 署名-非商业性使用-禁止演绎3.0 未本地化版本(...
阅读 1835·2021-11-25 09:43
阅读 2126·2021-11-19 09:40
阅读 3375·2021-11-18 13:12
阅读 1717·2021-09-29 09:35
阅读 616·2021-08-24 10:00
阅读 2487·2019-08-30 15:55
阅读 1688·2019-08-30 12:56
阅读 1766·2019-08-28 17:59