Angular13引入libxmljs后构建报无法解析fs、path模块错误

这不是libxmljs的bug，本质是将仅适用于Node.js环境的原生扩展类库错误引入了浏览器端Angular项目：

• libxmljs是封装libxml2的Node.js原生扩展，依赖bindings包加载本地编译的C++二进制文件，运行时强依赖Node.js专属的fs、path核心模块，以及Node.js独有的原生模块加载能力，这些能力在浏览器环境中完全不存在。
• Webpack 5 不再默认注入Node.js核心模块的浏览器polyfill，打包时解析依赖链路libxmljs -> bindings -> fs/path，到最底层发现找不到浏览器端对应的fs、path实现，就会抛出对应错误，错误指向bindings目录是依赖解析的正常表现，不是异常。
• 你之前尝试的配置browser字段、添加path polyfill的方案无法解决问题：就算手动补全fs、path的浏览器端模拟实现，libxmljs依赖的C++二进制文件也根本无法在浏览器中加载运行，这不是靠polyfill能填平的环境差异。

根据你的业务场景二选一即可：

• 若需要在浏览器端直接完成XML/XSD校验：直接替换libxmljs，选择纯JS或WebAssembly实现、兼容浏览器环境的XML处理库，比如xmllint-wasm（WASM封装的libxml2，支持完整XSD校验，无原生依赖，可直接在Angular中运行），不要选用任何带Node原生绑定的类库。
• 若XML校验逻辑不需要在浏览器执行：把libxmljs相关的校验逻辑迁移到后端服务实现，前端仅负责上传XML内容、调用后端校验接口拿结果即可。如果要保留相关代码不打进前端包，在webpack配置的externals字段中添加libxmljs，让打包时跳过对该包及其依赖的解析，之前的模块找不到错误会直接消失。

注意：你当前使用Maven构建前端项目，修改webpack配置时请确认修改的是构建流程实际加载的配置文件，避免修改未生效的冗余配置。

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