<!-- eslint-disable --> does not work in the v1.0.0-beta.6

1. I’ve found an error on the v1.0.0-beta.4: <!-- eslint-disable some-rule --> completely disables parsing the whole fragment and even the next fragment:

test.md

### Heading

Text

` ``js
console.log('a')

` ``

` ``js
console.log('b')

` ``

` ``js
console.log('c')

` ``

Error log:

   6:1   error  Use the global form of 'use strict'     strict
   6:17  error  Missing semicolon                       semi
  11:1   error  Use the global form of 'use strict'     strict
  11:17  error  Missing semicolon                       semi
  16:1   error  Use the global form of 'use strict'     strict
  16:17  error  Missing semicolon                       semi

test.md with comments:

### Heading

Text

<!-- eslint-disable strict -->
` ``js
console.log('a')

` ``

` ``js
console.log('b')

` ``

` ``js
console.log('c')

` ``

Error log (semi errors for the fragments 1 and 2 are not reported; fragment 2 is ignored):

  17:1   error  Use the global form of 'use strict'     strict
  17:17  error  Missing semicolon                       semi

2. So I’ve tried to update to v1.0.0-beta.6 and make a PR for Node.js. v1.0.0-beta.6 seems to fix this issue, but it has a new breaking one: code blocks with <!-- eslint-disable --> are parsed and throws if parsing errors found: test.md:

### Heading

Text

<!-- eslint-disable -->
` ``js
console.log('a') bang

` ``

Error log:

  7:18  error  Parsing error: Unexpected token bang

[btmills]

I just submitted a pull request to implement <!-- eslint-skip --> comments in Markdown: https://github.com/eslint/eslint-plugin-markdown/pull/73. Let me know what you think!

[btmills]

@vsemozhetbyt that makes sense, thanks for explaining.

As a first step, I tracked down what was causing the behavior you observed in beta.4. It turns out that the Markdown parser in use at the time wasn’t picking up code fences unless they were preceded by blank lines. I’ve added a test in #72 to make sure that doesn’t happen again.

<!-- eslint-disable -->

```js
// This block is seen by both beta.4 and beta.6
```

<!-- eslint-disable -->
```js
// This block is invisible to beta.4 but seen by beta.6
```

Since your disable comments and code fences were on adjacent lines, the processor wasn’t even getting those code blocks back from the parser. I’m glad that bug was fixed in a beta! 😅

Now, as for supporting your use case. I’d like to keep the meaning of eslint-disable the same in ESLint core and this processor, as I fear it could introduce confusion otherwise. With that in mind, how about I add support for a new <!-- eslint-skip --> comment that would exclude the code fence from parsing entirely? If that works for you, I’ll run it by the rest of the team to make sure I’m not stepping on any toes with that. It would look like this:

<!-- eslint-skip -->
```js
!@#$%^&*() <-- Doesn't even get parsed. The processor ignores this block entirely.
```

<!-- eslint-disable -->
```js
alert('Hello, ' + "world!") // Only check for syntax errors, ignore rules
```