'class' attribute value in preAttributes and codeAttributes doesn't work

[handreistoicescu]

Description

When a user adds a class attribute value to preAttributes or codeAttributes, nothing happens:

eleventyConfig.addPlugin(pluginSyntaxHighlight, {
    preAttributes: {
      class: "hey-this-is-a-custom-class-name",
    },
    codeAttributes: "this-is-also-custom-class-name",
});

Resulting DOM:

I assume this is because <pre> and <code> already have a class name that denotes the language being used (e.g. language-js).

Possible solutions

1. Maybe we can concatenate the new class names to the existing one, taking care not to overwrite the originals
2. ...or add the possibility for the user to add a wrapper element over the <pre>, because the scenario (at least in my case) is to add some layout styling to the code block (say, max-width):

eleventyConfig.addPlugin(pluginSyntaxHighlight, {
    wrapper: {
      element: "div",
      attributes: {
         // here be attributes
      }
    },
});

[handreistoicescu]

@zachleat I'd be happy to start working on this, but first it'd be awesome to get your input, so I'd be on the right path ✨

[WickyNilliams]

How about a function like:

eleventyConfig.addPlugin(pluginSyntaxHighlight, {
    wrap: inner => `<div class="a-custom-wrapper">${inner}</div>`
});

This is flexible, can be as simple or complex as you like, and would not complicate the plugin

[zachleat]

This was included as an addendum to #50. If you supply a class attribute to preAttributes or codeAttributes it will override the built-in class="language-${language}" class added to <pre> or <code> respectively.

[AleksandrHovhannisyan]

If you supply a class attribute to preAttributes or codeAttributes it will override the built-in class="language-${language}" class added to <pre> or <code> respectively.

@zachleat Out of curiosity, is there a way to preserve the default class name and append the custom class name? If I migrate back to this plugin in the future, I'd have a use case for this: contextual styling for a particular language but also some custom utility classes.

Edit: oh, you beat me to it: #66 (comment)

[zachleat]

No but it's easy enough to add it back in with the provided callback! The language is passed to the callback