Update remark

[wooorm]

Hi folks! 👋

I’ve updated remark! This does come with a change in HTML comments, so I had to use a loop around the getComments functionality.

I also removed remark directly. Rather, I added unified and remark-parse, which is a bit smaller, meaning faster installs.

Let me know if I should fix-up some code-style!

[jsf-clabot]

All committers have signed the CLA.

[btmills]

@wooorm thanks for this, and thanks for your work on remark!

Previously getComments would parse the html AST node that was passed to it. Now it looks like remark appears to split comments into distinct nodes - is that correct? If so, can I remove the parse5 step and just strip the <!-- and --> from the node's value?

[wooorm]

That’s correct, the following markdown:

<!--some eslint comment-->
<!--one more eslint comment-->
~~~js
code();
~~~

...is turned into:

{
  "type": "root",
  "children": [
    {
      "type": "html",
      "value": "<!--some eslint comment-->"
    },
    {
      "type": "html",
      "value": "<!--one more eslint comment-->"
    },
    {
      "type": "code",
      "lang": "js",
      "value": "code();"
    }
  ]
}

I’ll update the PR somewhere today!

[wooorm]

Done! Let me know if there’s some code-style I need to fix!

[platinumazure]

Do we want to support the line comments as well? (e.g., // eslint-disable-next-line someRule)

Probably a better question for @btmills, anyway.

[btmills]

@wooorm this is great, thank you!

I just tested, and the dependency changes in this PR result in a 27% reduction in node_modules size for a production install, down to 1.1MB from 1.5MB 🎉

@platinumazure that's a good point, right now the transform doesn't support eslint-disable-next-line since it has to be a line comment. That would be a separate change from this PR, so I'll merge without it, but it's worth considering whether the plugin needs to support eslint-disable-next-line in an HTML comment.

[wooorm]

Awesome! 👍