Missing position property for autolinks

[DMartens]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and discussions and couldn’t find anything (or linked relevant results below)

Affected package

mdast-util-gfm-autolink-literal@latest

Steps to reproduce

https://stackblitz.com/edit/stackblitz-starters-atlpfbvy?file=index.js

Hello [World][https://example.com]

Actual behavior

The three child nodes in the paragraph node do not have a position property.

Expected behavior

The nodes have a position property. As far as I understand is the position may only be unset if there is no corresponding text in the source.

Runtime

node@25.6.0

Package manager

pnpm@10.27.0

Operating system

Arch Linux

Build and bundle tools

No response

[wooorm]

What you show is not an autolink, and what you link to does not show this package.

Please explain, thank you

[DMartens]

Oh I am sorry I forgot to fork the stackblitz for another reproduction, I updated the link in the original description.
The autolink is inside the square brackets "https://example.com".
My guess is that the autolink takes precedence (the issue stems from a user mistakingly using square brackets twice to define a link).

[wooorm]

The example in OP / that you link to is still:

import { gfmAutolinkLiteral } from 'micromark-extension-gfm-autolink-literal'
import { fromMarkdown } from 'mdast-util-from-markdown'
import { gfmAutolinkLiteralFromMarkdown } from 'mdast-util-gfm-autolink-literal'

const code = 'Hello [World][https://example.com]'

const tree = fromMarkdown(code, {
  extensions: [gfmAutolinkLiteral()],
  mdastExtensions: [gfmAutolinkLiteralFromMarkdown()],
})
console.log(tree.children[0].children[0])

const without = fromMarkdown(code)
console.log(without.children[0].children[0])

😅 so I don’t really understand what you mean!

[DMartens]

My assumption is that all nodes in the AST have a position property.
According to the types from @types they may be missing if the created node is not present in the source text but I could not find any official documentation regarding this.
But for this code "Hello [World][https://example.com]", the transform creates 3 nodes each without a position property:

• Text: "Hello [World]["
• Link: https://example.com
• Text: "]"

While without using the transform, one Text node is created with a position property, so I think the problem is with this transformation.
In other words: The missing position property seems to be the result of the surrounding square brackets.

[ChristianMurphy]

My assumption is that all nodes in the AST have a position property

Not all do, autolink is one example

According to the types from @types they may be missing if the created node is not present in the source text but I could not find any official documentation regarding this.

Official docs https://github.com/syntax-tree/unist?tab=readme-ov-file#nodes

But for this code [World][https://example.com]

Why this code? That is not quite a valid link [World](https://example.com), or a valid link reference [World][].
So yes, garbage in, garbage out

[DMartens]

Not all do, autolink is one example

No autolinks have usually a position property (example).

Official docs syntax-tree/unist#nodes
The autolink is present in the code and not generated, so the position property should be set

Why this code? That is not quite a valid link World, or a valid link reference [World][].
So yes, garbage in, garbage out

Because this is exactly the code that is breaking this transformation.
This problem came up because a user of the ESLint markdown plugin did not use the proper syntax and we expected the position property to be present.
Further this is not "garbage in, garbage out" as this is valid syntax.

[wooorm]

Oh, that’s what you mean, I think I get it now.

This is explained in the readme: https://github.com/syntax-tree/mdast-util-gfm-autolink-literal#what-is-this. There are 2 algorithms that GH uses. One as a syntax extension, the other as an AST transform. It’s unfortunate, this limitation of GH. But I am not aware of an acceptable alternative!

[remcohaszing]

I’m running into the same problem in MDX analyzer. That only parses markdown, it doesn’t perform any transforms. So no nodes are generated.

According to unist:

A node is generated if it does not have positional information.

This is an example of a document that can’t be processed by MDX analyzer if remark-gfm is enabled:

<span>test\@example.com</span>

However, this works fine:

<span>test@example.com</span>

The different ASTs can be easily observed in the playgrounds at https://remark.js.org and https://mdxjs.com/playground.

The example with a slash, generates

{
  "type": "link",
  "title": null,
  "url": "mailto:test@example.com",
  "children": [
    {
      "type": "text",
      "value": "test@example.com"
    }
  ]
}

But if you remove the slash, positional information is added.

[lumirlumir]

Has there been any progress on this issue? If there's anything I can do to help, I'd be happy to.