[v1.1.7] Build Artifact Issue: Mismatch in chunkmodules.js (Named vs Numeric IDs)
[v1.1.7] 针对 chunkmodules.js 的构建问题反馈 (Named 与 Numeric ID 冲突)
Hi FoF team, thank you for your amazing work on this extension!
FoF 团队你们好,非常感谢你们维护这个优秀的扩展!
I’m reaching out to report a frontend error in v1.1.7 that wasn't present in v1.1.5.
我想反馈一个在 1.1.7 版本中出现、但在 1.1.5 中正常的严重前端报错。
When attempting to crop an avatar, it throws ChunkLoadError: Loading chunk 158 failed followed by a TypeError.
在尝试裁剪头像时,控制台会抛出 ChunkLoadError: Loading chunk 158 failed 以及随后的 TypeError。
After some debugging, the issue seems to be with the bundling of chunk~modules.js in this specific release:
经过排查,问题似乎出在这一版本中 chunk~modules.js 文件的打包方式上:
The main bundle expects a numeric Chunk ID (158), but chunk~modules.js registers itself as ["modules"].
主程序在寻找数字形式的 Chunk ID (158),但 chunk~modules.js 却是以具名 ["modules"] 进行注册的。
Also, the modules inside use named paths (e.g., ./node_modules/...) instead of the numeric IDs the manifest expects.
此外,该异步文件内部的模块使用了路径字符串作为键名,而主程序的索引表似乎仍在尝试通过数字 ID 来调用它们。
It appears v1.1.7 might have been built with development settings or an incorrect Webpack configuration.
看起来 1.1.7 版本在打包发布时,可能无意中使用了开发模式或错误的 Webpack 配置。
Although the plugin has moved to 2.0, many of us are still maintaining sites on the Flarum 1.x branch.
虽然插件已经更新到了 2.0,但我们仍有很多站点运行在 Flarum 1.x 分支上。
Managing out-of-sync local fixes or forks is quite a headache for long-term maintenance.
对于长期维护来说,管理与官方分支不一致的本地补丁或分支确实让人非常头疼。
If possible, could you please re-trigger a clean production build for the 1.x branch?
如果方便的话,能否请你们考虑针对 1.x 分支重新进行一次干净的生产环境打包并发布?
This would be a huge help for the community, especially for those who cannot re-compile assets themselves.
这将对社区非常有帮助,特别是对于那些无法自行重新编译静态资源的用户。
Note: This technical analysis was assisted by Gemini. I'm not 100% sure if it's correct, so please double-check.
注:此技术分析由 Gemini 协助完成。我不确定结论是否完全准确,请开发者参考并自行核实。
Thanks again for your time and support!
再次感谢你们的时间与支持!