DataEase2.10.11源码编译，使用项目中的
Dockerfile构建镜像部署后前端浏览器控制台报错：
appearance-0.0.0-dataease.js:9
Uncaught ReferenceError: Cannot access 'M' before initialization
at appearance-0.0.0-dataease.js:9:17155
(匿名) @ appearance-0.0.0-dataease.js:9
变量在初始化前被访问，您这边源码做过改动吗？
源码基本不动，只做一定的修改防止打包不报错：
- package.json 里把jsencrypt 从 ^3.3.2 固定成了精确版本 3.3.2
- package-lock.json 也已经同步锁到 3.3.2
打包本地运行一样的问题。
源码下载地址https://github.com/dataease/dataease/archive/refs/tags/v2.10.11.zip
改动的是后端代码不是前端的
参考的就是这个源码文档哈，就是不行哈。不清楚源码是不是有问题。
前后端代码没有任何改动，单纯编译部署就是会有报错，git也有相同issus，并不是不能复现，看起来不一定是同一个版本
https://github.com/dataease/dataease/issues/18187
再次重申 源码基本不动，只做一定的修改防止打包不报错：
- package.json 里把jsencrypt 从 ^3.3.2 固定成了精确版本 3.3.2
- package-lock.json 也已经同步锁到 3.3.2
附：源码下载地址 https://github.com/dataease/dataease/archive/refs/tags/v2.10.11.zip
codex 打包时 执行报错如下
export JAVA_HOME=$(/usr/libexec/java_home -v 21) && export PATH="$JAVA_HOME/bin:$PATH" && mvn -version && mvn clean package -Pstandalone -U -Dmaven.test.skip=true -s /Users/randy/CODE/java_repository/dataease-2.10.11/tmp-maven-settings.xml
运行失败
已处理 3m 40s
情况很简单，不是你命令写错了，也不是 Node 没装上。
发生的是这三步：
npm install 成功了
这说明 Node 和 npm 都正常，网络也至少够把前端依赖装下来。
失败在前端“打包”阶段，不在“安装依赖”阶段
报错是前端代码里这句导入：
import JSEncrypt from 'jsencrypt/bin/jsencrypt.min'
但现在实际安装到的 jsencrypt 包版本，不再允许这样引用内部文件。
所以我帮你把它改成了新版兼容写法
改成：
import JSEncrypt from 'jsencrypt'
也就是说，根因是：
不是 Node 缺失
不是 Maven 缺失
不是 Java 21 这一步有问题
是前端依赖 jsencrypt 的引用方式和当前安装版本不兼容
我已经改了文件 encryption.ts，你现在再执行一次原命令就行：
export JAVA_HOME=$(/usr/libexec/java_home -v 21)
export PATH="$JAVA_HOME/bin:$PATH"
mvn clean package -Pstandalone -U -Dmaven.test.skip=true -s /Users/randy/CODE/java_repository/dataease-2.10.11/tmp-maven-settings.xml
如果你愿意，我下一步可以继续帮你看“这次改完后还能不能一次打包过”。
1 个文件已更改
撤销
core/core-frontend/src/utils/encryption.ts
先尽量不去动源码先撤销修改，
然后看看是不是安装依赖的时候，默认的依赖版本和源码要求的版本不匹配导致的。
已处理 1m 10s
是的，这条线基本成立，而且我已经把源码改动撤销了。
现在我们确认到的事实是：
encryption.ts 已恢复成原来的写法：
import JSEncrypt from 'jsencrypt/bin/jsencrypt.min'
core-frontend/pom.xml 的 maven-clean-plugin 会在 clean 阶段删除：
node_modules
*-lock.json，也就是会删掉 package-lock.json
当前 package-lock.json 里锁到的 jsencrypt 版本已经是 3.5.4
而源码使用的是老式深路径导入 jsencrypt/bin/jsencrypt.min
jsencrypt@3.5.4 的包导出规则不再允许这种导入，所以 Vite 打包时报：
Missing "./bin/jsencrypt.min" specifier in "jsencrypt" package
所以结论就是：
这次更像是“构建脚本删掉锁文件后，npm install 重新解析到了一个比源码预期更新的依赖版本”，而不是单纯网络问题。
最关键的根因点在这里：
package.json 里写的是 "jsencrypt": "^3.3.2"
^3.3.2 允许升级到 3.5.4
clean 又把锁文件删了
于是每次构建都可能装到更新版本
新版本和旧源码导入方式不兼容
如果你想坚持“不动源码”，那下一步最合理的是改“依赖解析方式”，通常有两种做法：
把 jsencrypt 从 ^3.3.2 固定成一个和当前源码兼容的精确版本
不要在 clean 时删除 package-lock.json，并改用更稳定的锁定安装方式
如果你愿意，我下一步可以继续帮你走“完全不改业务源码”的方案，优先把依赖版本锁死并验证打包。
1 个文件已更改
撤销
core/core-frontend/src/utils/encryption.ts
把 jsencrypt 从 ^3.3.2 固定成一个和当前源码兼容的精确版本
已处理 3m 33s
已经按你这个方向处理好了，而且没有再动业务源码。
现在的状态是：
package.json 里已经把
jsencrypt 从 ^3.3.2 固定成了精确版本 3.3.2
package-lock.json 也已经同步锁到 3.3.2
encryption.ts 保持原样，还是：
import JSEncrypt from 'jsencrypt/bin/jsencrypt.min'
我还额外确认了本地安装到的包里确实存在 node_modules/jsencrypt/bin/jsencrypt.min.js
所以这次修复的思路是成立的：不是改源码适配新版本，而是把依赖版本锁回和当前源码兼容的版本。
补一句关键点：即使 mvn clean 会删掉 package-lock.json，现在因为 package.json 也已经是精确版本 3.3.2，后续重新安装时也会优先拿这个固定版本，不会再漂到 3.5.4。
如果你愿意，我下一步就继续帮你重新跑一遍 core 的打包命令，验证这次是否已经打通。