当前位置:Gxlcms > JavaScript > Webpack服务器端代码打包实例详解

Webpack服务器端代码打包实例详解

时间:2021-07-01 10:21:17 帮助过:41人阅读

环境变量

之前,我们在项目里会经常使用 process.env.NODE_ENV, 但这个变量对于 webpack打包是有影响的, 在 production 的时候是有优化的.本文主要和大家介绍Webpack 服务器端代码打包的示例代码,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧,希望能帮助到大家。

我们将改用其他的环境变量来区别:


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 后端项目中, 动态配置加载一般是这样写:


为了提高阅读性, 和可能存在ENV的复用, 我们会单独定义一个变量.

在 webpack 打包的项目中直接这样做的话, 会产生一个问题. 比如我现在有多个配置:

  • _develpment.js

  • _test.js

  • _production.js

  • _staging.js

即便我传入的当前环境为 development, 依然所有的配置文件会被全部打包进来(只是永远不会被执行). 那么这样的话, 就存在敏感信息泄露的风险.

正确的姿势应该是这样的:

config/index.js


模块化打包

比如, 我在项目中有很多个模块, 处于负载均衡的需求, 或者是对于客户定制模块化产品的需求, 我们需要分模块进行打包, 避免其他模块(永远不会被执行的)被打包进 webpack bundle.


在服务端加载的时候, 是这样子的:


那么就需要 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/webpack-server-bundle

相关推荐:

PHP简单系统查询模块代码打包下载_PHP教程

以上就是Webpack服务器端代码打包实例详解的详细内容,更多请关注Gxl网其它相关文章!

人气教程排行