Why was the support for <-- comments removed?

[ovflowd]

I understand that MDX wants to encourage you to use JSX comments. But when you have use cases like legacy Apps with hundreds and hundreds of block comments <-- it makes the migration extremely painful. (I might be missing something here)

I'm just genuinely curious about the historical decision process behind it and why there are no "compatibility" plugins/options for MDX.

[wooorm]

extremely painful

Use a regex to replace <!-- with {/* and --> with */}, or a plugin, or use the .md extension if you want markdown.

randomly decide

No, it was a very careful decision to make what is markdown and what is JS(X) unambiguous. If you want to migrate from markdown, you don’t need to migrate, use an .md extension.

genuinely curious

• RFC: MDX comment syntax #1042
• How to force xdm to support HTML comments? wooorm/xdm#44
• Cannot use <!-- for comments with xdm, but Prettier cannot use {/**/} for comments wooorm/xdm#61

"compatibility" plugins/options

a) there is a plugin.
b) because MDX before v2 passed everything that looked like XML through as JS(X) to Babel/Webpack. We can’t codemod that. We can’t support that. From v2 on, we have an actual AST, which can be transformed, so we can do that.

[ovflowd]

Thanks for the fast reply! I've added some notes on a separate comment, but I appreciate the quick and thorough reply :)

[ovflowd]

Use a regex to replace with/}, or a plugin, or use the .md` extension if you want markdown.

This is not a feasible option when you have hundreds of files. I cannot feasibly ask the other collaborators to review each one of the 700+ file changes and guarantee them that these changes are safe. (Assuming I'm going the regex route)

No, it was a very careful decision to make what is markdown and what is JS(X) unambiguous. If you want to migrate from markdown, you don’t need to migrate, use an .md extension.

If I import a plain Markdown file inside MDX, it will be treated as MDX. So, there's an issue here, not sure if it's a bug or per design. But that's minor, honestly.

a) there is a plugin.

Which plugin? And what does that plugin does?

[ovflowd]

Maybe the MDX setup that Nextra is doing is incorrec.t @wooorm is there something we need to pass to the processor options from mdx-js to treat .md` as regular MD?

[remcohaszing]

This line processes the source from string. https://github.com/shuding/nextra/blob/238dea3881165df3244c2b3a23944ac438b3721d/packages/nextra/src/compile.ts#L94

MDX infers MDX/markdown mode based on the file path. You should pass a vfile compatible object instead

{
  value: source,
  path: filePath
}

[ovflowd]

@shuding ☝️

[ovflowd]

Btw @remcohaszing thank you for going deep and finding this!

[remcohaszing]

Sorry, my bad! compile() does this internally, then passes the format option to createProcessor(). So you’ll need to do something like this instead (resolveFileAndOptions()):

createProcessor({
  format: filePath.toLowerCase().endsWith('.md') ? 'markdown' : 'mdx'
})

Still, it’s a good idea to pass path to process. External plugins may use this.