shadow-cljs构建ClojureScript时simple优化报$jscomp.inherits未定义问题咨询

两类报错的共同触发逻辑 #

• 你遇到的两类报错本质是同一个根源：项目引入的外部JS依赖包含ES6类继承语法，编译阶段没有正确加载Closure Compiler的配套运行时垫片；同时部分老旧依赖存在全局作用域污染问题，在高级优化的变量重命名阶段触发了标识符解析错位。
• $jscomp.inherits是Closure Compiler为处理ES6类继承自动注入的内部工具函数，当编译产物中引用了这个函数，但负责挂载它的基础垫片脚本没有被正确加载、或是被其他代码提前覆盖/清除时，就会直接抛出“该函数不存在”的错误。
• 开启pseudo-names配置后报错自动消失，是因为这个配置会关闭高级优化阶段的激进短变量重命名逻辑，保留原有变量的可读性映射，从根源上避免跨文件的标识符混淆——但这只是临时规避方案，没有解决底层冲突。

各报错的具体触发场景 #

• simple优化下的模块批量加载失败+$jscomp.inherits报错：通常是项目里引入的某个npm包/本地JS文件自带了独立的全局$jscomp对象，且它的加载顺序早于shadow-cljs自动注入的Closure垫片，加载时直接把全局原有$jscomp对象上挂载的inherits方法覆盖为空值；或是编译时引入了已经被Closure编译过、带类继承逻辑的JS包，但没有开启shadow-cljs对应的外部依赖垫片注入开关。
• advanced优化下的“某短名变量is not a function”乱码报错：是因为有JS依赖在运行时往全局作用域挂载了和ClojureScript内部变量同名的标识符，激进重命名后两个不同来源的变量被映射到了同一个短名称，调用时自然出现“本该是函数的变量被替换成其他值”的错位问题——这也是为什么开pseudo-names就不会触发错误：变量不会被压缩成短名，不存在重名冲突的空间。

优先排查模块加载顺序问题 #

• 打开浏览器源码面板，搜索全局的$jscomp对象，定位它的赋值时机和来源文件；如果发现是某个第三方JS文件在加载时直接执行了window.$jscomp = {}覆盖了原有对象，要么调整这个文件的加载顺序到shadow-cljs编译产物之后，要么在该文件加载完成后补手动的垫片初始化逻辑。
• 检查shadow-cljs.edn配置，对引入的带ES6类的JS依赖，正确标注依赖类型：对于没有UMD包装、直接引用全局类的依赖，不要直接用:require引入，而是通过:foreign-libs配置加载，同时开启:language-in :es2015，让编译器自动注入对应的继承垫片。

修复高级优化下的标识符冲突 #

• 针对advanced模式下出现的随机函数不存在的报错，按堆栈定位到具体出问题的ClojureScript命名空间后，检查对应命名空间下是否存在和引入的JS全局变量重名的自定义变量；如果有，给ClojureScript侧的变量加专属前缀避免重名即可。
• 临时验证方案：可以先开启:pseudo-names true跑通全流程业务逻辑，确认没有其他业务逻辑错误后，再逐个排查重名变量，逐步关闭这个配置恢复编译压缩比。

高频踩坑提醒 #

• 不要在simple优化模式下手动引入外部的Closure Compiler垫片文件，这类文件会和shadow-cljs自动注入的版本冲突，直接导致全局$jscomp对象被覆盖。
• 如果引入的是经过webpack/rollup打包的JS库，优先选择完成模块化封装、不依赖全局变量的版本，这类未做模块化隔离的库是触发高级优化标识符冲突的最高发来源。

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