Should ignore lang string after the first space

[Francisco Ryan Tolmasky I]

If you have a code fence like this:

```javascript more stuff
5 + 5
```

Most markdown interpreters simply ignore everything after the space and treat the syntax coloring based only on the first part. For example, if you view the source of this very comment, you'll see that the code fences below is "javascript test" and not just "javascript". This is very useful because it allows one to provide additional functionality. In particular, on the node site we are going to have javascript runkit to turn on "runnability" on certain code blocks ( nodejs/node#22831 ). The fix is very simple, just changing:

if (node.lang && SUPPORTED_SYNTAXES.indexOf(node.lang.toLowerCase()) >= 0) {

to:

if (node.lang && SUPPORTED_SYNTAXES.indexOf(node.lang.split(" ")[0].toLowerCase()) >= 0) {

I'm happy to submit this change but wanted to run it by everyone here first.

[Simon Brunel]

@btmills It looks like this doesn't work anymore in v2.0.0-rc.0 (e.g. ```js is linted while ```js live is not). I'm wondering if it's on purpose (i.e. replaced by the files pattern matching override) or if it's actually broken.

[Brandon Mills]

@simonbrunel thanks for testing out the v2 RC! We have a test for that, so I don't have any immediate ideas what's going on.

eslint-plugin-markdown/tests/lib/processor.js

Lines 271 to 280 in d30c50f

 it("should ignore anything after the first word of the info string", () => { 
     const code = [ 
         "```js more words are ignored", 
         "var answer = 6 * 7;", 
         "```" 
     ].join("\n"); 
     const blocks = processor.preprocess(code); 
  
     assert.strictEqual(blocks.length, 1); 
 }); 

If you've extended plugin:markdown/recommended or enabled processor: 'markdown/markdown' on *.md files, it should be picking up ```js live just like any other js code block. Can you open a new issue with more information, including your configuration and more of the Markdown contents?

[Simon Brunel]

@btmills I just submitted #166. The test you mentioned doesn't guarantee that the block will be further processed by ESLint after glob matching of the blocks[0].filename.