0.22.0 minified version does not parse inline links correctly

[pcj]

With example input:

# H1

Lorem ipsum.

## H2

[link][foo]

[foo]: http://foo.com

### H3

1. Item 1
2. Item 2

* Bullet 1
* Bullet 2

    ~~~
    blockquote here
    ~~~

* An example [link](http://example.com 'link title').

And the unminified dist/commonmark.js, the (correct) parse tree is:

Document
.Header
..Text# H1
.Paragraph
..Text# Lorem i...
.Header
..Text# H2
.Paragraph
..Link
...Text# link
.Header
..Text# H3
.List
..Item
...Paragraph
....Text# Item 1
..Item
...Paragraph
....Text# Item 2
.List
..Item
...Paragraph
....Text# Bullet 1
..Item
...Paragraph
....Text# Bullet 2
...CodeBlock# blockqu...
..Item
...Paragraph
....Text# An exam...
....Link
.....Text# link
....Text# .

However, using dist/commonmark.min.js, the parse tree is:

Document
.Header
..Text# H1
.Paragraph
..Text# Lorem i...
.Header
..Text# H2
.Paragraph
..Link
...Text# link
.Header
..Text# H3
.List
..Item
...Paragraph
....Text# Item 1
..Item
...Paragraph
....Text# Item 2
.List
..Item
...Paragraph
....Text# Bullet 1
..Item
...Paragraph
....Text# Bullet 2
...CodeBlock# blockqu...
..Item
...Paragraph
....Text# An exam...
....Text# [
....Text# link
....Text# ]
....Text# (http:/...
....Text# '
....Text# link title
....Text# '
....Text# ).

Any ideas? I am just reporting this observation, I have not tried to look into why the minified version displays this behavior. I am seeing the same thing with master 8fefa4954a76bd1b78fe7144c4aef7d4eb499cc3 as well.

Regards,
Paul

[jgm]

Interesting. You can reproduce this with just

[link](http://example.com 'link title')

and the culprit seems (experimentally) to be the title, since removing it creates a link again. Haven't had a chance to investigate further.

[jgm]

I guess by definition this counts as a bug in uglify, but we're better off if we can track down ourselves where things are going wrong.

[pcj]

Maybe uglify is handling this part wrong? This other issue mentions a long list of && expressions, sounds like a similar bug. Perhaps unwrapping it to if/then statements would fix the problem. I'll try it if you don't get to it first.

see mishoo/UglifyJS#751

   if (this.peek() === C_OPEN_PAREN) {
        this.pos++;
        if (this.spnl() &&
            ((dest = this.parseLinkDestination()) !== null) &&
            this.spnl() &&
            // make sure there's a space before the title:
            (reWhitespaceChar.test(this.subject.charAt(this.pos - 1)) &&
             (title = this.parseLinkTitle()) || true) &&
            this.spnl() &&
            this.peek() === C_CLOSE_PAREN) {
            this.pos += 1;
            matched = true;
        }
    } else {

https://github.com/jgm/commonmark.js/blob/master/lib/inlines.js#L608

[pcj]

It may be as simple as making sure uglifyjs is up to date.

[pcj]

Yes that fixed it. Looks like they addressed this rather serious uglifyjs bug in July. You probably need to update your installed version. Here's the version that works for me:

$ uglifyjs --version
uglify-js 2.5.0