Initial release checklist (1.0.0)

[43081j]

This is just a tracking issue for what needs doing before this is published publically:

• investigate whether is* functions should be migrated into parse5 core (or exported if they already exist)
• Compatibility with google/lit #3
• Compatibility with modernweb #4
• Add unit tests #5
• split monolithic code up into individual files if needed
• ensure traversal function interfaces are agreed upon and implementation works as expected
• create a migration PR in the lit repo
• create a migration PR in the modernweb repo
• add a CI setup

Most of this will be about compat with google/mw repos as they're the primary users of dom5 these days. There are other consumers (incl myself) but i'd argue we shouldn't try maintain the old interfaces as there will be many unused functions google only ever made use of.

Possible gaps in parse5

I've had to create these internal functions:

• isDocument
• isDocumentFragment
• isTemplateNode
• isParentNode
• isChildNode

I feel like most of these should really be part of the tree adapter interface, since thats where the others currently live (e.g. isTextNode, isElementNode, etc).

cc @fb55

also @fb55 i can't see the settings of this repo now that i moved it into parse5 org (to be able to make it public eventually). do you know if im just missing a permission? i also want to rename it to just tools i think

also would be nice to cc some people into here before it gets published (e.g. some of lit/mw teams) so maybe we need to make it public but just not publish it yet

[fb55]

@43081j Sorry for the delay — was afk for ~two weeks, now back again. I've made you an owner of the org — thought that was already the case, sorry for that!

My instinct is to have parse5-tooks re-export the existing is* methods from the adapter. I'm also not opposed to adding them to the adapter; my only concern is that the adapters not having all of the same methods might be confusing to some.

[43081j]

no worries, everyone needs a break :D

My instinct is to have parse5-tooks re-export the existing is* methods from the adapter

This makes sense i think, so the consumer doesn't need to directly import the default tree adapter every time.

my only concern is that the adapters not having all of the same methods might be confusing to some

as in not all adapters would have the same methods? we'd have to add it to them all i think.

maybe easier for now to leave those alone and keep these functions here...

also cc @justinfagnani @rictic @daKmoR - you might be interested in this repo/issue as the aim here is to at least be a good replacement for the copies of dom5 you each have (lit, modernweb). some methods have changed, some signatures, etc, but it should support everything both repos need.

[43081j]

@fb55 could you help me out getting parse5 org access in npm? so i can publish a pre-release of this and start preparing PRs to google & modernweb?

[fb55]

@43081j Sent you an invite!

[43081j]

awesome thank you :D

[justinfagnani]

Do you think this could be dual-published with CommonJS and standard modules before 1.0?

I'm trying to use this in the context of a TS Server plugin, which is sync and CommonJ only, so it's much easier to consume CJS modules.

[43081j]

It's possible I think. It's a shame to have to duplicate the published code, though

I wonder if node will ship require(esm) soon enough and backported?

Otherwise maybe we just ship a dual package and drop it once the require stuff is widely available

[fb55]

require(esm) was shipped with Node 23

[43081j]

Do you know if it'll get backported?

I don't think we can restrict to >=23. So many consumers are on the few majors before that

If it won't soon enough, maybe we could survive with a dual package temporarily and just take the size hit. It's not a huge package so should still be small