eleventy: Disable markdown indented code blocks by default

In markdown there is a specific feature called Indented Code Blocks that causes much confusion! We have a big warning on the docs about it.

https://www.11ty.dev/docs/languages/markdown/#there-are-extra-and-in-my-output

Awhile back @drewm posted a lovely workaround to opt-out of this feature.

eleventyConfig.setLibrary("md", markdownIt(options).disable('code'));

https://twitter.com/drewm/status/1167821259662663682

I’d like to change the default Eleventy behavior to do this as well. Maybe even in 2.0 👀

Related: #402 #180 #1971 (#1635 maybe) and part of https://twitter.com/brob/status/1530620544680337412 from @brob and probably a bunch of others

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 34
  • Comments: 19 (9 by maintainers)

Commits related to this issue

Most upvoted comments

Opt-ing back into this feature will be a little trickier than I suggested earlier, I went pretty hard on this default based on how the existing Markdown documentation looks with setLibrary and Markdown plugins.

Put plainly, this calls .disable("code") on both the default library instance and any instance set via setLibrary too.

So, to opt-back-in I added a new (multi-template-language) configuration API method called amendLibrary that allows you to run your own callbacks on both default and custom library instances.

Here’s what that looks like for this feature specifically:

// Opt-back-in via new 2.0 amendLibrary Configuration API method.
eleventyConfig.amendLibrary("md", mdLib => mdLib.enable('code'));

But this will also simplify markdown-it plugins too, so you don’t have to know anything about the existing markdown-it options or passing those in (credit to @pdehaan above for that callout)

const mdEmoji = require("markdown-it-emoji");

module.exports = function(eleventyConfig) {
  eleventyConfig.amendLibrary("md", mdLib => mdLib.use(mdEmoji));
};

Yeah @AleksandrHovhannisyan I’m updating the docs as we speak/type 🙌🏻

YESSSSSS. This is such a pain point.

I prefer using my own code block syntax (liquid or nunjucks tag) and have been bitten by this a number of times.

Totally in agreement on this.

Additionally, I feel like any time something behaves unexpectedly is also a time for new users (and often newer devs) to get very confused. When magic happens, it should be more explicit.

I’d be curious to know how many folks actively use tab-based code blocks. To me, that’s a relatively unintuitive way of handling it on markdown’s part (but that ship has sailed)

Whew, time to issue a mercy rule on this one. It’ll ship with 2.0.0-canary.12

Agreed, the “indent for code” was a mistake in the design of Markdown IMO. Get rid! 😃

I LOVE this! I was running my own fork of MarkdownIt because of this and I’m very glad Eleventy 2.0 has a better way to disable it.

Woo-hoo! 🥳 This has bitten me way too many times.

Should the pitfall docs also be updated to mention that outdent is no longer needed as of 2.0.0-canary.12? (Or maybe that should happen when 2.0 goes live.)

Yes, yes, 100% yes. Possum paws up for this. This is such an unknown markdown feature, that the unintended problems it causes are rarely attributed to it. I think this is a wonderful quality of life improvement.

Huge support for this.

Yes please. Omitting indented code blocks is the major divergence that Bikeshed-flavored Markdown makes from CommonMark as well; it’s a terrible misfeature on it’s own and is even worse when combined with markup.

@AleksandrHovhannisyan correct, the traditional method (triple backtick) for code blocks and inline code (single backtick) in Markdown both still work when .disable("code") is in play.

Enabling or disabling the triple backtick feature is referenced as fence in markdown-it and the single backtick feature is backticks

https://github.com/markdown-it/markdown-it#manage-rules

Just to clarify, this doesn’t break code blocks or inline code, right? I tried it out and it seems to work fine, and I’m also 100% in support of this since it’s bitten me way too many times. I do agree that it’s probably better to stick it behind an option, though, and maybe set it to true by default while allowing users to opt out if they need to.

I think this would be a very sensible default since I feel that most users don’t even know about the feature and it creates a gotcha. Personally, I’ve been desabling the code feature in every projects.