[CommonMark] Link mis-parsing when following a reference

[ikatyang]

Subject of the issue

commonmark: true

[1][Test Text](http://example.com)

Steps to reproduce

astexplorer

Expected behaviour

Same as CommonMark playground:

[
    {
        "type": "text",
        "value": "["
    },
    {
        "type": "text",
        "value": "1"
    },
    {
        "type": "text",
        "value": "]"
    },
    {
        "type": "link",
        "title": null,
        "url": "http://example.com",
        "children": [
            {
            "type": "text",
            "value": "Test Text"
            }
        ]
    }
]

Actual behaviour

[
    {
        "type": "linkReference",
        "identifier": "test text",
        "referenceType": "full",
        "children": [
            {
                "type": "text",
                "value": "1"
            }
        ]
    },
    {
        "type": "text",
        "value": "("
    },
    {
        "type": "link",
        "title": null,
        "url": "http://example.com",
        "children": [
            {
                "type": "text",
                "value": "http://example.com"
            }
        ]
    },
    {
        "type": "text",
        "value": ")"
    }
]

[zalum]

+1

[ChristianMurphy]

Pull requests are welcome

[wooorm]

I think it’s confusing that:

[alpha][bravo](http://charlie.com)

[alpha][delta](http://charlie.com)

[bravo]: https://bravo.com

Yields (in CM, not remark):

<p><a href="https://bravo.com">alpha</a>(http://charlie.com)</p>
<p>[alpha]<a href="http://charlie.com">delta</a></p>

I would say that whether a definition exists or not should not affect parsing (it of course should affect compilation).

[wooorm]

Heya, just wanted to give an update about micromark, it’s sort-of a new motor that we’ll soon use in remark to parse markdown. It’s not yet 100% ready but will be relatively soon. The good news is, it fixes this issue! (P.S. see this twitter thread for some more info!)

[wooorm]

Sorry for the wait! I just wanted to share that there’s now a PR that solves this issue: #536.