发布 f `@xmldom/xmldom`

语境

来源：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。

0.9.0 (2024-08-29)

但是我今天要讲的是自 2022 年 10 月以来在 next 标签下发布的所有内容。

我对这些变化感到非常兴奋，因为它们为未来潜在的变化提供了明确的基础。

tldr：与规范更加一致，差异尽可能明确。

1. 强制mimetype交还控制权

使实现变得复杂的一个方面是解析 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`snew DOMParser({onError: onErrorStopParsing}).parseFromString(...)// prevent parsing of XML that has `warning`snew DOMParser({onError: onWarningStopParsing}).parseFromString(...)

comparedocumentposition，扩展 html 实体，null 而不是 undefined，...

原始 xmldom 存储库的另一个分支通过将 html 实体扩展到完整集（在 0.8.x 中也可用）并移植comparedocumentposition api 的实现，使其重新回到我们的存储库中。谢谢你，欢迎@zorkow

在此过程中，xmldom 迄今为止返回未定义而不是 null 的几个地方已得到修复，以符合规范。

而且我发现前作者似乎更喜欢在很多地方从列表的末尾开始迭代，属性在多个地方以相反的顺序处理，现在已修复。

removechild api 的实现发生了很大的变化，以符合规范并在应该抛出 domexception 的时候。

并且修复了 3 个相关错误，明确说明了 xmldom 的未来方向：
仅当适当严格的 xml 解析不受其影响时，才会提供对宽松 html 解析规则的支持。
以前（已损坏的）html 中自动自关闭标签的“支持”已经消失了。

coctype内部子集

最近，@shunkica 投入了大量的时间来解决以前处理 !doctype 内部子集部分时出现的大量问题。

它现在被保留为文档文档类型的internalsubset属性的一部分，并且现在可以正确检测到许多错误的文档类型声明并报告为 fatalerror。

同时感谢@kboshold 在该领域的最新错误修复。

在此过程中，我们创建了一个包含相关语法正则表达式的新模块，正确性检查基于这些模块，并且测试正确地覆盖了它们。

xmldom 的目标不是成为验证解析器，但这是支持那些带有更复杂 dtd 的文档的重要一步。

还有更多

到目前为止，开发是使用 node v10 完成的，因为这也是 xmldom 当前支持的最低版本。作为即将推出的版本工作的一部分，我决定切换到 v18 进行开发，因为越来越多的 devdependency 也使这成为最低要求。从该版本开始，这将是目前新的最低运行时版本。

我发起了一项公众投票/讨论，询问人们他们需要支持哪个版本的 node 或其他运行时。
如果没有反馈表明有什么不同，下一个重大版本很可能会放弃对某些旧 node 版本的支持。

一路走来，很多 api 都收到了具有正确类型的 jsdoc 注释。

谢谢

感谢您花时间阅读所有这些。

这些变化相当大，我很高兴能够交付这些变化。

我希望你和我一样兴奋:)

如果您需要更多详细信息，可以查看非常详细的变更日志，或者前往存储库并加入或开始讨论或提出问题。