xmldom 是一个 javascript ponyfill，用于向其他运行时提供现代浏览器中存在的以下 api： 将 xml 字符串转换为 dom 树 new domparser().parsefromstring(xml, mimetype) => document 创建、访问和修改 dom 树 new domimplementation().createdocument(...) => document 将 dom 树序列化回 xml 字符串 new xmlserializer().serializetostring(node) => string
来源：xmldom 自述文件
自从我在 2020 年 6 月开始为分叉的 xmldom 库做出贡献以来，已经发布了 40 个版本。
这是一个非常有趣且具有挑战性的项目，并且很可能会在相当长的一段时间内保持这种状态。
据 github 称，自分叉以来已有 50 多人为其做出了贡献。
再次感谢所有贡献者。
这并不包括所有设法从原始无作用域 xmldom 包迁移到有作用域 @xmldom/xmldom 包版本 0.7.0 以获得所有安全修复程序的人。
作为 lts 标签发布的最新版本是 0.7.13。
最后一个具有重大更改的版本是 0.8.0，发布于 2021 年 12 月 22 日，大约 3 年前。
最新发布的版本是0.8.10。
但是我今天要讲的是自 2022 年 10 月以来在 next 标签下发布的所有内容。
我对这些变化感到非常兴奋，因为它们为未来潜在的变化提供了明确的基础。
tldr：与规范更加一致，差异尽可能明确。
使实现变得复杂的一个方面是解析 xml 与 html 的规则不同。
xmldom（在某种程度上）从一开始就“支持”这两种风格。甚至根本不需要传递 mimetype：应用什么规则是根据当前正在解析的 xml 字符串/节点的当前默认命名空间决定的。
这以 0.9.0 结束：从现在开始，domparser.parsefromstring(xml, mimetype) 中的 mimetype 是强制性的，并且是唯一被检查以决定是否应用 xml 或 html 规则的东西。巴斯塔。
该信息会保留在生成的文档（新类型属性）中，因此在序列化它时，会再次应用正确的规则。
这是一个巨大的（并且可能是破坏性的）变化，但我真的很高兴它已经准备好了，因为它使大量相关的错误修复变得可能/更容易实现，并且还降低了 api 和实现的复杂性。
此外，它现在只接受指定的 mime 类型，并在任何其他情况下抛出 typeerror。
我个人对原生浏览器 api 的错误处理感到困惑的是，它总是返回一个 document，如果出现问题，parsererror 节点将是主体的第一个子节点：
由于错误处理在 xmldom 中从来没有以这种方式工作，但现有的错误处理非常复杂、混乱且文档记录很差，0.9.0 对其进行了简化，现在对解析过程中发生的任何潜在错误具有（更加）一致的行为：
它会抛出一个 parseerror ?，例如有下列情况之一的：
仍然有一些情况会被报告为警告（尤其是在解析 html 时）或错误，但不会阻止数据的处理，但是新的错误处理可以很容易地决定代码的严格程度需要使用 xmldom。
可以传递给 domparser 构造函数的（不符合规范的）选项称为 onerror。
它需要一个具有以下签名的函数：
function onerror(level:errorlevel, message:string, context: domhandler):void;
建议应用其中一个来在出现任何意外的第一个信号时停止处理 xml：
// prevent parsing of XML that has `error`s
new DOMParser({onError: onErrorStopParsing}).parseFromString(...)
// prevent parsing of XML that has `warning`s
new DOMParser({onError: onWarningStopParsing}).parseFromString(...)
原始 xmldom 存储库的另一个分支通过将 html 实体扩展到完整集（在 0.8.x 中也可用）并移植comparedocumentposition api 的实现，使其重新回到我们的存储库中。谢谢你，欢迎@zorkow
在此过程中，xmldom 迄今为止返回未定义而不是 null 的几个地方已得到修复，以符合规范。
而且我发现前作者似乎更喜欢在很多地方从列表的末尾开始迭代，属性在多个地方以相反的顺序处理，现在已修复。
removechild api 的实现发生了很大的变化，以符合规范并在应该抛出 domexception 的时候。
并且修复了 3 个相关错误，明确说明了 xmldom 的未来方向：
仅当适当严格的 xml 解析不受其影响时，才会提供对宽松 html 解析规则的支持。
以前（已损坏的）html 中自动自关闭标签的“支持”已经消失了。
最近，@shunkica 投入了大量的时间来解决以前处理 !doctype 内部子集部分时出现的大量问题。
它现在被保留为文档文档类型的internalsubset属性的一部分，并且现在可以正确检测到许多错误的文档类型声明并报告为 fatalerror。
同时感谢@kboshold 在该领域的最新错误修复。
在此过程中，我们创建了一个包含相关语法正则表达式的新模块，正确性检查基于这些模块，并且测试正确地覆盖了它们。
xmldom 的目标不是成为验证解析器，但这是支持那些带有更复杂 dtd 的文档的重要一步。
到目前为止，开发是使用 node v10 完成的，因为这也是 xmldom 当前支持的最低版本。作为即将推出的版本工作的一部分，我决定切换到 v18 进行开发，因为越来越多的 devdependency 也使这成为最低要求。从该版本开始，这将是目前新的最低运行时版本。
我发起了一项公众投票/讨论，询问人们他们需要支持哪个版本的 node 或其他运行时。
如果没有反馈表明有什么不同，下一个重大版本很可能会放弃对某些旧 node 版本的支持。
一路走来，很多 api 都收到了具有正确类型的 jsdoc 注释。
感谢您花时间阅读所有这些。
这些变化相当大，我很高兴能够交付这些变化。
我希望你和我一样兴奋:)
如果您需要更多详细信息，可以查看非常详细的变更日志，或者前往存储库并加入或开始讨论或提出问题。