基于JSP的遗留Java应用模块依赖打包方案咨询

你的现有方案评估 #

方案1：将依赖挂载到全局作用域 #

这个方案是可行的，具体操作是在dummy入口文件中明确把需要暴露的变量挂载到window对象：

// dummy-entry.js
import { RFB } from 'rfb.js';
// 挂载到全局，建议用带项目前缀的命名避免冲突
window.MyApp_RFB = RFB;

然后用打包工具（比如esbuild）执行打包：

esbuild dummy-entry.js --bundle --outfile=bundled-rfb.js

打包后的IIFE会自动执行，把MyApp_RFB注入到全局，JSP中的内联脚本就能直接访问这个变量。
潜在影响：如果全局空间中存在同名变量会引发冲突，所以务必给挂载的变量加独特前缀（比如项目名），减少污染全局的风险。

方案2：删除IIFE包裹代码 #

不推荐使用这个方案。模块打包后的代码通常包含大量内部私有变量/函数，去掉IIFE后这些变量会直接暴露在全局作用域，极易和旧版JS的变量冲突，导致不可预期的逻辑错误，后续维护难度极大。

更优方案推荐 #

1. 整合内联脚本到打包流程 #

如果JSP中的内联JS代码没有依赖Java后端注入的动态变量，可以直接把这部分代码移到dummy入口文件中：

// dummy-entry.js
import { RFB } from 'rfb.js';

// 原JSP内联脚本中的业务逻辑
// do some stuff...
// do some stuff with RFB

打包后，JSP中只需引入打包好的文件即可：

<script src="bundled-rfb.js"></script>

这种方式完全遵循打包工具的规范，没有全局污染，代码维护性最好。

2. 用打包工具参数指定全局挂载对象 #

如果必须保留JSP内联脚本，可以通过打包工具的参数，让打包后的代码挂载到一个统一的全局对象上，而非零散的变量：
以esbuild为例，执行打包命令时指定--global-name：

esbuild dummy-entry.js --bundle --format=iife --global-name=MyApp --outfile=bundled-rfb.js

同时在dummy入口中导出需要的依赖：

// dummy-entry.js
import { RFB } from 'rfb.js';
export { RFB };

打包后会生成类似var MyApp = (() => { ... return { RFB: RFB } })()的代码，JSP内联脚本中可以通过MyApp.RFB访问依赖，既避免了零散的全局变量，又能满足内联脚本的需求。

3. 打包为UMD格式兼容多环境 #

如果你的项目同时存在模块脚本和旧版全局脚本，可以打包为UMD格式，兼容两种场景：

esbuild dummy-entry.js --bundle --format=umd --global-name=MyApp --outfile=bundled-rfb.js

这种格式的打包文件既可以作为ES模块被import，也能在全局作用域通过MyApp访问依赖，适配混合技术栈的遗留项目。

内容的提问来源于stack exchange，提问作者David Hofmann