Update XAST after node removal

[guillaumegarcia13]

I have a XAST tree on which I removed some nodes using unist-util-remove successfully.
In order to have a look at modifications, I also use unist-util-inspect.

Positions in the output of unist-util-inspect are not updated after removal.
Surely, I can update the whole thing with fromXml(toXml(...)) but it's rather cumbersome.

Is there a way for the XAST tree to update its positions?
Thx.

[ChristianMurphy]

@guillaumegarcia13 some context on position.

The position field represents the location of a node in a source document
https://github.com/syntax-tree/unist#node

Meaning it is intended to map back to it's original position.

If you feel strongly that there should be changed, it is a possibility, but would have broad impacts on unified/syntax-tree as a whole, it should probably be an RFC https://github.com/unifiedjs/rfcs
It may be technically possible, but the cost of complexity and development effort being worth the benefit, isn't clear yet.

---

Setting that aside for a moment, this sounds like an XY Problem.
Reading between the lines a bit, the confusion is mostly around what inspect is printing? Is that accurate?
Would using something like https://github.com/syntax-tree/unist-util-remove-position, in your pipeline, to scrub the positions before inspecting produce output you would find clearer and easier to understand?

[guillaumegarcia13]

Thanks! 🙏🏻

I do need the positions, it is the main reason I am using the unist-util-inspect to check that my "split at" function is behaving as expected.

I understand the philosophy of unist-util-inspect to reference original position.
That being said, it might be interesting to know whether the AST has been modified and no longer "in synced".
Recreating the tree after each modification is actually not so much of a big deal when one knows inspect's inner workings.

[wooorm]

It’s not really about inspect — that it shows positional info.

It’s more that I think nodes should have their original positional info, even if they‘re changed a bit. But nodes that are generated (not in the source file), should not have positional info. More in syntax-tree/unist.

With two examples:

a) say we’re using remark to lint and format markdown (which I’m doing in all my readmes). So we use remark-toc to generate a table of contents, and remark-lint to check tons of things.
The nodes in the ToC are generated, so they don’t have positional info. remark-lint ignores nodes without positional info.
So users wont get lint messages about generated code,.

b) Say we have a processor that turns markdown, to HTML, to JS(X) (such as xdm). On the JavaScript tree, we’d now use a hypothetical project that checks for alt on img nodes, and whether they’re valid.
That plugin can now check both markdown syntax and JSX syntax, and point back to exactly where the mistake was made, because the positional info remained.

[guillaumegarcia13]

Thank you.

OK, much clearer why position should remain attached to original document (position in part of the node, inspect is the UI-friendly way of showing it but does not hold the position). I had it all mixed up! 😵

Hence, in my case, as I'm producing a new document, it makes sense to recreate a whole tree to leverage the new positional info and use inspect to show it.