Parsing Markdown code fence metadata

[johnhooks]

I really like the concept of using metadata in the code fence to specify how to display the content of a code block. There seem to be a lot of different ways to do it. I like the Rehype Pretty Code syntax for it, but the way they parse it is pretty basic and not made available. I have a functional concept that uses a subset of JavaScript syntax, which makes it really easy to use acorn with a custom plugin to make it work.

They do something like this:

```js title="cool example" {1,3..4} showLineNumbers{10} /highlight_words/
// Some super cool highlighted code.
```

I propose this

```js title="cool example" highlight(1,3..4) lineNumbers(10) /$highlight full RegExp?/i
// Some super cool highlighted code.
```

So after saying all that, I have this cool parser, but what would be the right way to expose it? Is it possible to make it available to other plugins? I read about the data attribute, and I've seen some plugins add to it. But is that correct?

This is what I'm considering...

const transformer: Transformer<Root> = (ast) => {
  visit(ast, "code", (node: Code, index: number | null, parent: Parent | null) => {
    if (!node.meta) {
      return;
    }
    if (!node.lang) {
      return;
    }

    const estree = metaParser.parse(node.meta, { ecmaVersion: "latest" }) as BaseNode as Program;
    const metadata = buildMetadata(estree);

    parent!.children[index!] = {
      data: { metadata },
    };
  });
};

Thanks for any help.

[johnhooks]

Sorry, I meant to post this is the UnifiedJS discussion board, which is where I was told it was best to post questions like this. If I could delete it and move it I would, let me know if I should repost it there.

[ChristianMurphy]

Here works too 👍

[johnhooks]

lol thanks!

[ChristianMurphy]

Howdy @johnhooks! 🤠 👋

So after saying all that, I have this cool parser, but what would be the right way to expose it?

To be sure I understand

• "it" in this context is the metadata associated with the code block?
• That metadata comes out as an ESTree encoded JavaScript program?
• Is the plan for that metadata to be consumed by a remark, rehype, or recma plugin? (or some combination of them)

---

Without that context my best guess is that you want to interpret that JavaScript in a rehype plugin to generate HTML with syntax highlighting?

If that's the case, I'd consider using data.hName, data.hProperties, and or data.hChildren so that mdast-util-to-hast knows to pass that data through to the next syntax tree format.
See: https://github.com/syntax-tree/mdast-util-to-hast#fields-on-nodes

[johnhooks]

"it" in this context is the metadata associated with the code block?

Yes

That metadata comes out as an ESTree encoded JavaScript program?

I was building a custom parser, and I decided I was rebuilding something that was already build. So I picking up acorn and created a plugin for it, acorn is battle tested and it even pulls out the RegExps and validates them, which is really helpful for this. I wasn't planning on "running" the estree as a program, but walk the ast to build a metadata object that would be typed something like this.

export type Metadata = {
  highlighted: number[];
  lineNumbersStart: number;
  showLineNumbers: boolean;
  highlightedWords: RegExp[];
  title?: string | undefined;
  lang?: string | undefined;
};

Is the plan for that metadata to be consumed by a remark, rehype, or recma plugin? (or some combination of them)

Yes that is my intent. I am making a highlighting plugin and I'm parsing all the metadata, but I thought it would be better to extract it.

I will read the article about fields on nodes, thanks.

[johnhooks]

@ChristianMurphy after reading the article, I wouldn't just pass the data down, but do it as a fully constructed hast structure?

[ChristianMurphy]

Having most of the logic live in rehype/hast allows for the plugin to be simpler and more interoperability with other unified/rehype plugins.
(remark plugins generally don't inspect the data.h* properties of other plugins)
@wooorm may also be able to add more insights here.
Having recently deprecated https://github.com/remarkjs/remark-highlight.js#readme in favor of https://github.com/rehypejs/rehype-highlight#readme

[johnhooks]

I think I understand the general strategy. Passing the metadata down isn't how the UnifiedJS system works. I'll just break it out into a regular package and use it in the highlighter which will be a remark plugin. Thanks for walking me though it @ChristianMurphy, I appreciate your help.