feat(markdown): support fenced codeblock lang followed by attributes

[ikatyang]

Fixes #4150

• support ```js {something=something}
• does not support ```js{something=something}

[kachkaev]

How about adding limit to split?

const lang = node.lang.split(/\s/, 1)[0];

We only use [0] so there is no point in extracting all words from the string

[ikatyang]

Sure 👍

[kachkaev]

@ikatyang sorry for a bit of off-topic, but since we're got code embedding here, do you know how a language parser can know that what it's formatting is a part of markdown, not a standalone file? Is there any flag getting passed down the tree that could help detect that? Just asked about this on gitter 🤔

[ikatyang]

Should be options.parentParser, though there's no docs for it.

prettier/src/main/multiparser.js

Line 21 in e237320

parentParser: parentOptions.parser,

[kachkaev]

Thank you for this hint @ikatyang! Indeed, parentParser was there! 🎉

function parse(text, parsers, opts) {
  const isCodeBlockInMarkdown = opts.parentParser === 'markdown';

  // ...
}

Really looking forward to see the result of this PR on npm! 😍 When about is Prettier team planning to cut a new release?

[kachkaev]

@ikatyang could you recall a reason why we decided not to support js{something=something}?

Atom turns on syntax highlighting for code blocks even without spaces, which makes things a bit confusing four us in litvis:

When it is visible that the code's language has been detected, there is an expectation that it will be formatted by Prettier too, but this does not happen.

If I change the regexp to something like /^[a-z0-9_-]+/i and cover the new case with a test, would you accept this?

[ikatyang]

GitHub does not support it:

• ```js{something=something}
  const x = 1;
  ```

  const x = 1;
  

• ```js {something=something}
  const x = 1;
  ```

  const x = 1;

I won't object such change, though I think whitespace is more non-controversial.