parse5
parse5 copied to clipboard
inikulin
parse5/tools package
Google used to maintain a library called dom5 - a bunch of utils useful for traversing the parse5 AST amongst other things.
Various other projects also implement modified versions of this set of utils (e.g. modernweb, lit itself, etc.).
Recently, i've extracted most of this into its own "parse5 tools" repo (private for now) which all of these projects can depend on instead of shipping their own copy.
I think it'd make sense that we ship this in the parse5 namespace (@parse5/tools) or just as part of parse5 itself.
some examples of what it implements:
- querying the AST (query, queryAll)
- traversal of the AST with a visitor object
- mutation helpers (e.g. spliceChildren)
- traversal helpers (e.g. nextSiblings, previousSiblings, ancestors, etc.)
It is also hardcoded to use the default tree adapter (as was dom5), which i think makes sense still and keeps the types/impl simple. None of the dom5 consumers over the past several years have used a non-default adapter.
@fb55 what do you think?
I'm up for having this. Imho it should be a separate module outside of the core parse5 package. I am still split on whether it should be a part of the monorepo, or if we want to reactivate @parse5. For the monorepo, I feel like adapters should be used — but at that point, the htmlparser2 adapter already has access to all of the related tooling for htmlparser2 and wouldn't need this; this feature would only be . Curious what your take is.
As a (very optional) aside: It might make sense for the interface to target css-select's adapter interface. Even if coverage isn't entirely there, it would make it easier for users to query the DOM.
much of the functionality already exists in the tree adapter these days, so im not sure trying to match that interface would make sense. the things not provided by the adapters are a bit more nuanced.
if it was up to me, i'd publish it as @parse5/tools or something but keep it in a separate repo, not in the monorepo. i think adding it to this repo will overcomplicate it, so better to keep it apart.
the current implementation i have is basically the parts of dom5 still in use today, and the additional functions the modern web team depend on. but it would be good to discuss those interfaces/functions once we have a repo to open an issue in
Sounds good 👌
You should be able to create a new repositories in the @parse5 org – lmk if you encounter any issues.
I think we can close this with the https://github.com/parse5/parse5-tools repo :)
@abdonrd it is here:
https://github.com/parse5/parse5-tools
and published on npm under @parse5/tools.
iirc the lit repo now uses it
the modernweb PR went stale, i think thanks to a lower activity in general im seeing over there. but ill try pick it up some time
@abdonrd not anymore, good spot!
i feel like an idiot now :D totally didn't realise. the package had been published but not the repo