Rejoining xmldom-sre fork

[zorkow]

It is good too see a community forming around this package.

A few years back I forked the original and created a bespoke npm package xmldom-sre (https://www.npmjs.com/package/xmldom-sre) for use in development of the Speech Rule Engine (https://github.com/zorkow/speech-rule-engine), primarily for two reasons:

1. Include support for wicked good xpath.
2. Support the full set of HTML entities. (This is related to issue Allow custom entityMap to be passed as DOMParser option #71).

In case there is any interest in the above points I'll be happy to create PR and rejoin my fork.

However, you should be aware that this would increase your entities.js file by an order of magnitude.

[karfau]

Are you thinking of having some peer dependencies or of "bundling" everything into the package?

(Sorry, I did not yet take the time to check the details of your fork.)

Regarding xpath, I can personally imagine going for a peer dependency approach, that is only needed when calling certain functions.
So that people not interested in that part would not need to have it installed. But I'm not aware of the related API yet, so it's hard to say
Of course I would want to compare the current options to pick the most viable one, no idea if the one you picked back then still makes sense to pick nowadays.

For the entities, it's relevant that we will soon drop the support for implicitly parsing HTML as such, it will need to be enabled explicitly by passing the mime type. In this way a peer dependency approach might also work, but we are not quite there yet.

[zorkow]

For Xpath there would be no need for a dependency. All I did was fix some methods so wicked-good-xpath could work with xmldom as a DOM. I am a bit hazy about the details myself. This is what I wrote at the time:

This is a fork of jindw's xmldom library together with Rui Azevedo code for compareDocumentPosition.
It allows the use of wicked-good-xpath together with xmldom, using a little hack.

As for the HTML entities, I can see that a peer dependency would be a good idea as not to have to ship the large entities file when it's not needed.

I think as a next step -- when I get round to it -- I will have a look at your current version to see if wicked-good-xpath can work with it. If necessary I can then make a PR with the old fix.

[zorkow]

I have now updated the xmldom-sre to be in sync with the latest version of @xmldom/xmldom to fix security vulnerabilities.
So I am getting back to the proposal to join the packages:

1. I have made a PR feat: Add compareDocumentPosition method from level 3 spec. #488 with the Dom level 3 compareDocumentPosition method, which is helpful for working with xpath libraries.

2. If we could export the HTML_ENTITIES

   xmldom/lib/entities.js

   Line 33 in 535050f

   exports.HTML_ENTITIES = freeze({

   
   I could put together a package that would allow the import of the complete list of HTML entities, without polluting @xmldom/xmldom.

[zorkow]

Or maybe it is worth to add those extra 45k to the library instead of all the additional things that come with an additional package/dependency?

I think it is cleaner to have a top level export for HTML_ENTITIES and then have a package @xmldom/htmlentities that adds effectively the content of this file: https://html.spec.whatwg.org/entities.json

[karfau]

I didn't yet understand which problem exporting the html entities would solve.

In order to use them for parsing inside xmldom we need to pass them to DOMParser constructor in an option that doesn't exist yet.

And if it is always used as part of xmldom, I don't see the benefit of pitting it in a separate lib.

[zorkow]

And if it is always used as part of xmldom, I don't see the benefit of pitting it in a separate lib.

It will make life easier (at least for me) to have them all in xmldom. Do you want to me to follow up with a PR that adds them?

[karfau]

It will make life easier (at least for me) to have them all in xmldom. Do you want to me to follow up with a PR that adds them?

Yes, that would be great

[zorkow]

I've just made PR #489 for this purpose. Please have a look.

[karfau]

@zorkow I'm happy to announce that all your contributions have now been released to npm.

The changes from #488 are still only available as a beta, which is available as next version, together with other potentially breaking changes. For more details see #435
There are only two issues left for the 0.9.0 milestone (both labeled as "help-wanted"), but of course there is no ETA for it.

By the way: In case rejoining doesn't only mean code wise but also contribution wise, with whatever capacity/skills you can offer, I would be happy to get you on board.

[zorkow]

I am finally getting back to this.
Thanks @karfau for making the beta release.

I've integrated 0.9.0-beta.8 now into SRE and it works great, so it will be in the next SRE version and in the next MathJax beta release, which hopefully will be out soonish.

[karfau]

That's great news.

Are you interested in joining as a maintainer, now that you contributed that functionality?

[zorkow]

Thanks for the kind request, but I am afraid I have to decline. I am too overcommitted to projects as it is.

But I'll be happy to contribute fixes or features, if and when we need them in SRE, MathJax, or other projects I use xmldom.

So please keep up the good work. It is a great library!

[zorkow]

First time ever, I am closing a discussion on github!
Whoo-hoo!