Libérez .f `@xmldom/xmldom`

Contexte

xmldom est un ponyfill javascript pour fournir les API suivantes présentes dans les navigateurs modernes à d'autres environnements d'exécution :

• convertir une chaîne XML en arborescence DOM

  new DOMParser().parseFromString(xml, mimeType) =>  Document

• créer, accéder et modifier une arborescence DOM

  new DOMImplementation().createDocument(...) => Document

• sérialiser une arborescence DOM dans une chaîne XML

  new XMLSerializer().serializeToString(node) => string

Source : fichier Lisezmoi xmldom

Histoire

Depuis que j'ai commencé à contribuer à la bibliothèque forked xmldom en juin 2020, il y a eu 40 versions.

C'est un projet très intéressant et stimulant et il le restera probablement pendant un bon bout de temps.

Selon GitHub, plus de 50 personnes y ont contribué depuis son fork.

Merci encore à tous les contributeurs.

Et cela ne compte pas toutes les personnes qui ont réussi à passer du package XMLdom d'origine sans portée au package @xmldom/xmldom version 0.7.0 pour obtenir tous les correctifs de sécurité.
La version la plus récente publiée sous le nom de balise lts est la 0.7.13.

La dernière version avec des modifications importantes était la 0.8.0, sortie le 22 décembre 2021, il y a presque 3 ans.
La version la plus récente publiée est la 0.8.10.

0.9.0 (2024-08-29)

Mais ce dont je veux parler aujourd'hui, c'est de tout ce qui a été publié sous le prochain tag depuis octobre 2022.

Je suis vraiment enthousiasmé par ces changements car ils fournissent une base claire pour de futurs changements potentiels.

TLDR : plus d'alignement avec les spécifications et les différences sont rendues aussi explicites que possible.

1. Appliquer mimeType pour redonner le contrôle

Un aspect qui rend la mise en œuvre complexe est qu'il existe des règles différentes pour analyser XML et HTML.
xmldom (dans une certaine mesure) "a pris en charge" les deux versions depuis le début. Il n'était même pas nécessaire de transmettre un mimeType : les règles à appliquer étaient décidées en fonction de l'espace de noms par défaut actuel de la chaîne/du nœud XML en cours d'analyse.

Cela se termine par 0.9.0 : à partir de maintenant, le mimeType dans DOMParser.parseFromString(xml, mimeType) est obligatoire et c'est la seule chose qui est jamais vérifiée pour décider d'appliquer les règles XML ou HTML. Basta.

Et ces informations sont conservées dans le document résultant (nouvelle propriété de type), donc lors de sa sérialisation, les règles appropriées sont à nouveau appliquées.

Il s'agissait d'un changement massif (et potentiellement révolutionnaire), mais je suis vraiment ravi qu'il soit prêt, car il a rendu possible/beaucoup plus simple à mettre en œuvre des tonnes de corrections de bogues associées et réduit également la complexité de l'API et de la mise en œuvre.

De plus, il n'accepte désormais que les types MIME spécifiés et renvoie une TypeError dans les autres cas.

Rigueur et gestion des erreurs

Un aspect qui me rend personnellement confus à propos de la gestion des erreurs de l'API native du navigateur est qu'elle renvoie toujours un document et si quelque chose ne va pas, un nœud parsererror sera le premier enfant du corps :

Comme la gestion des erreurs n'a jamais fonctionné de cette façon dans XMLdom mais que la gestion des erreurs existante était très complexe, déroutante et mal documentée, la version 0.9.0 la simplifie et a désormais un comportement (beaucoup plus) cohérent envers toute erreur potentielle qui se produit lors de l'analyse :
Il lance une ParseError ?, par exemple. dans l'un des cas suivants :

• Dans les versions précédentes, il était possible pour certaines chaînes XML mal formées, que le document renvoyé n'ait pas de documentElement, ce qui conduirait très probablement à des TypeErrors plus tard dans le code.
• Plusieurs chaînes XML mal formées seront désormais correctement signalées comme fatalError, ce qui empêche désormais toujours tout traitement ultérieur.
• Plusieurs éléments qui n'étaient pas signalés auparavant comme une erreur ou qui n'étaient signalés que comme un avertissement sont désormais également signalés comme une erreur fatale.

Il reste encore des cas qui sont signalés comme un avertissement (en particulier lors de l'analyse HTML) ou comme une erreur qui n'empêchent pas le traitement des données, mais la nouvelle gestion des erreurs permet de décider très facilement du degré de rigueur du code qui utilise XMLdom doit l'être.

L'option (non conforme aux spécifications) qui peut être transmise au constructeur DOMParser est appelée onError.
il prend une fonction avec la signature suivante :

function onError(level:ErrorLevel, message:string, context: DOMHandler):void;

• ErrorLevel est soit un avertissement, une erreur ou une erreur fatale.
• xmldom fournit déjà une implémentation pour les deux cas d'utilisation les plus courants :
  • onErrorStopParsing pour lancer également une ParseError pour tous les problèmes de niveau d'erreur
  • onWarningStopParsing pour lancer également une ParseError pour tous les problèmes de niveau d'erreur

Il est recommandé d'en appliquer une pour arrêter le traitement du XML au premier signal inattendu :

// 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(...)

compareDocumentPosition, extended HTML entities , null instead of undefined, ...

Another fork of the original xmldom repository made it's way back into our repo by extending the HTML entities to the complete set (also available in 0.8.x) and porting over the implementation of the compareDocumentPosition API. Thank you, and welcome @zorkow

Along the way several places where xmldom so far returned undefined instead of null, have been fixed to adhere to the spec.

And I discovered that the former author seems to have preferred iterating from the end of a list in so many places, that attributes were processed in the reverse order in multiple places, which is now fixed.

The implementation of the removeChild API changed quite a bit, to comply to the spec and throws a DOMException when it should.

And 3 related bugs were fixed in a way that clearly states what the future direction of xmldom is:
Support for lax HTML parsing rules will only be provided if proper strict XML parsing doesn't suffer from it.
The former (broken) "support" for automatic self closing tags in HTML is gone.

coctype internalSubset

More recently @shunkica invested a huge amount of time end effort to fix tons of issues in the former handling of the internalSubset part of the !DOCTYPE.

It is now preserved as part of the internalSubset property of the doctype of a Document and many wrong doctype declarations are now correctly detected as such and reported as a fatalError.

Also thanks to @kboshold for the latest bug fix in this area.

Along the way we created a new module containing regular expressions for the relevant grammar, and correctness checks are based on those and they are properly covered by tests.

It is not the goal of xmldom to become a validating parser, but this a great step to support those documents that come with more complex DTDs.

And there is even more

Up to now development was done using Node v10, since this is also the lowest version xmldom currently supports. As part of the work on the upcoming version, I decided to switch to v18 for development, since more and more devDependencies also made this a minimum requirement. This will be the new minimum runtime version for the time being starting with this release.

I initiated a public poll / dicussion to ask people which version of Node or other runtimes they need support for.
The next breaking release will most likely drop support for some older Node versions, if there is no feedback indicating something different.

Along the way plenty of APIs have received jsdoc comments with proper types.

Thank you

for taking the time to read through all of this.

Those are quite some changes, and I'm very excited to be able to ship those.

I hope you are as excited as I am :)

If you need more details you can go through the very detailed changelog, or head over to the repository and join or start a discussion or file an issue.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!