(rehype-highlight) How to programmatically ignore certain code blocks?

[HerbCaudill]

I have some MDX pages that use rehype-highlight for syntax highlighting. I'd also like to use Sandpack to provide little runnable sandboxes, the way the React docs do (example, code).

So I need for rehype-highlight to act on standalone code blocks, but not on code blocks that are inside a <Sandpack> component.

// test.mdx
# Test

```js
const foo = () => {
    console.log('rehype-highlight should apply syntax highlighting here')
}
``` 

<Sandpack>

```js 
const foo = () => {
    console.log('rehype-highlight should not touch this')
}
```

</Sandpack>

According to the rehype-highlight docs, you can add a no-highlight class to a <code> block to have the highlighter ignore it. So I've tried inserting a little rehype plugin to add no-highlight to code blocks that are generated inside a <Sandbox> component. The plugin is doing what it's supposed to -- it's applying the class:

But in spite of the no-highlight class, the code block is still getting the highlighter markup applied to it, which gets in the way of my Sandpack component parsing it.

I've made a CodeSandbox repro here:
http://codesandbox.io/p/sandbox/sandpack-vs-remark-rehype-rnh3tx

Is there a better way to programmatically get rehype-highlight to ignore code blocks that are inside a <Sandpack> component?

[ChristianMurphy]

Welcome @HerbCaudill! 👋
Sorry you ran into a spot of trouble.

According to the rehype-highlight docs, you can add a no-highlight class to a <code> block to have the highlighter ignore it.

Note that it expects no-highlight/nohighlight to be the first, or the only class on the <code> tag.
Your plugin is adding it as the second and final.
Which means the language detector will choose the language you selected https://github.com/rehypejs/rehype-highlight/blob/81f7dd1c383ffe0d5432584c3a66d281bbe9aa84/lib/index.js#L157-L179

This can be resolved by prepending the class with unshift.
Working example: https://codesandbox.io/p/sandbox/sandpack-vs-remark-rehype-forked-v6f7tr?file=%2Flib%2FloadMdx.ts%3A22%2C38

plugin source from sandbox

import { serialize } from 'next-mdx-remote/serialize';
import rehypeHighlight from 'rehype-highlight';
import { visit } from 'unist-util-visit';
import { Plugin } from 'unified';

export const loadMdx = async (source: string) => {
  const serialized = await serialize(source, {
    mdxOptions: {
      remarkPlugins: [],
      rehypePlugins: [rehypeNoHighlightInSandbox, rehypeHighlight]
    }
  });
  return serialized;
};

function rehypeNoHighlightInSandbox(): Plugin {
  const addClass = (node: any, className: string) => {
    node.properties = node.properties || {};
    node.properties.className = node.properties.className || [];
    if (typeof node.properties.className === 'string')
      node.properties.className = [node.properties.className];
    node.properties.className.unshift(className);
  };

  return (tree) => {
    visit(tree, 'mdxJsxFlowElement', (node) => {
      if (node.name === 'Sandpack') {
        const preNodes = node.children.filter(
          (child: any) => child.tagName === 'pre'
        );
        preNodes.forEach((preNode) => {
          const codeNode = preNode.children[0];
          addClass(codeNode, 'no-highlight');
        });
        console.log(JSON.stringify(node, null, 3));
      }
    });
  };
}

Is there a better way to programmatically get rehype-highlight to ignore code blocks that are inside a <Sandpack> component?

Using a rehype plugin seems like a good solution.
Prepending the class name will resolve the issue at hand.

Open to discussion on whether no-highlight/nohighlight should be supported anywhere inside the class name list.
My initial thought is the current solution handles everything in a single pass and is fairly performant.
Applying both a language and not highlighting feels like an edge case we may not need to handle.
I'd lean towards leaving it as is, but open to thoughts otherwise.

[HerbCaudill]

Ah sweet - that makes total sense.

It might not hurt to emphasize in the docs that no-highlight needs to be first - I can submit a PR.

I get the internal logic now -- that no-highlight is treated as kind of a pseudo-language designation, and that certain languages (or no language designation) will cause the code block not to be styled.

I didn't understand that until now, and it explains behavior that had previously frustrated me, which is that a code block with no language tag would be left completely untouched. So I had to find another way to apply the .hljs class, or duplicate its styles in my own stylesheet, which felt janky.

My mental model was that tagging code as txt or leaving off the language tag would fall back on a trivial "grammar" that would treat the entire block as a single token, but that would still apply the base formatting to the container.

I'd suggest that the current approach muddles together two orthogonal concerns -- what language the code block is in, and whether you want the block to be touched at all. Here's how I would think about the intent represented by various combinations:

• language-txt no-highlight - this is just text that I want to be rendered with <pre> font and whitespace; leave it completely alone
• language-txt - this is text that I want rendered consistently with other code blocks, but it has no syntax so there's nothing to highlight internally
• language-js no-highlight - I want to mark this as javascript code -- perhaps to get editor support, prettier formatting, or (my current use case) because that's information that a containing component needs -- but I don't want syntax highlighting or anything, leave it completely alone
• language-js - I want javascript syntax highlighting

[ChristianMurphy]

My initial take:

Open to discussion on whether no-highlight/nohighlight should be supported anywhere inside the class name list.
My initial thought is the current solution handles everything in a single pass and is fairly performant.
Applying both a language and not highlighting feels like an edge case we may not need to handle.
I'd lean towards leaving it as is, but open to thoughts otherwise.

If you think handling in an order insensitive way would be simple and fast.
It could make sense to update the logic.

[HerbCaudill]

I've opened an issue with a proposal to separate the highlight/no-highlight concern from the which-language concern.
rehypejs/rehype-highlight#28

[wooorm]

To me that reads as a different issue than the OP here. Is this OP no longer a problem?

[HerbCaudill]

To me that reads as a different issue than the OP here. Is this OP no longer a problem?

Yeah, it's a different issue. I can create a separate issue for the OP, asking to support no-highlight in any position in the class list (or at least to document the existing unstated requirement to have it first).

[wooorm]

No worries. See rehypejs/rehype-highlight@8fbc0eb