Add an option to specify different rules inside a markdown file

[aduh95]

I'm trying to set up a rule set that is able to discriminate between ESM examples and CJS code snippets inside the markdown documentation:

```js esm
export default {};
```
```js cjs
'use strict';
module.exports = {};
```

The issue is that only the js is passed through unfied lang data, and the part after the space is pass to the meta option:

{
  type: 'html',
  lang: 'js',
  meta: 'esm',
  value: 'export default {};',
  position: {
    start: { line: 1, column: 1, offset: 0 },
    end: { line: 3, column: 4, offset: 32 }
  }
}
{
  type: 'html',
  lang: 'js',
  meta: 'cjs',
  value: "'use strict';\nmodule.exports = {};",
  position: {
    start: { line: 4, column: 1, offset: 33 },
    end: { line: 7, column: 4, offset: 81 }
  }
}

I wish there was a way to create separate rules for those blocks, something like:

// .eslintrc.js
module.exports = {
    plugins: ["markdown"],
    overrides: [
        {
            files: ["**/*.md/*.js:cjs"],
            parserOption: { sourceType: "script" },
            rules: {
                // ...
            }
        },
        {
            files: ["**/*.md/*.js:esm"],
            parserOption: { sourceType: "module" },
            rules: {
                // ...
            }
        },
    ]
};

EDIT: I'm using remark-parse 9.0.0, the meta property doesn't seem to be available in remark-parse 5.x this repo is using.

[btmills]

Are you able to use ```cjs and ```mjs fences instead of ```js? That would allow you to configure **/*.md/*.cjs and **/*.md/*.mjs separately.

[aduh95]

Sure, but that doesn't address the underlining issue: I'd still want to have the option to specify different set of overrides for a same language. Ignoring those meta strings may be fine for some people, but I think it can be a very useful feature for others.

If we want to make a breaking change, I think now (I.E. before v2 is released) would be the right time as folks upgrading to v2 are going too have to rewrite their ESLint configuration anyway.
If such a breaking change is not acceptable, maybe we could make this configurable/opt-in?

[btmills]

While I agree switching functionality based on the meta string is neat, there'd need to be some important use case for which that route is the only option. One downside is that it claims exclusive use of the meta string. What if there are other tools that want to use it as well?

Let's step back from the specific implementation idea. What use case are you trying to achieve?

I think now (I.E. before v2 is released) would be the right time

v2 was already a release candidate when you opened this issue, so any breaking change would have to wait for a hypothetical v3.

[aduh95]

One downside is that it claims exclusive use of the meta string.

I'm not sure that's true, you can easily configure the plugin to ignore it – in the implementation I made in #172 at least:

            "files": [
                "**/*.{md,mkdn,mdown,markdown}/*.{js,javascript,jsx,node}",
                "**/*.{md,mkdn,mdown,markdown}/*.{js,javascript,jsx,node}:*"
            ]

It's too bad ESLint doesn't allow users to pass a pluginOptions object to introduce that kind of changes in a non-breaking way.

What use case are you trying to achieve?

I'm working on this PR: #172
Like I said in the OP, I would like to add different rule sets for both blocks, and the current rules on that repo forbid to use cjs or mjs as language descriptor (warning Incorrect code language flag fenced-code-flag remark-lint).
Also, I can imagine we want to introduce more specific rule sets in the future.

v2 was already a release candidate when you opened this issue, so any breaking change would have to wait for a hypothetical v3.

Hum OK I didn't realize v2 was already feature frozen. I still think it would still be a neat feature to have, so maybe for later?

[btmills]

the current rules on that repo forbid to use cjs or mjs as language descriptor (warning Incorrect code language flag fenced-code-flag remark-lint)

It sounds like the ideal fix is for remark-lint to allow cjs and mjs in info strings, and this change would be a workaround for that solution. Are you able to configure remark-lint that way, and if so, does that solve your use case for now?

[aduh95]

Yep that works indeed.

…

Le 1 mai 2021 à 05:28, Brandon Mills ***@***.***> a écrit :  the current rules on that repo forbid to use cjs or mjs as language descriptor (warning Incorrect code language flag fenced-code-flag remark-lint) It sounds like the ideal fix is for remark-lint to allow cjs and mjs in info strings, and this change would be a workaround for that solution. Are you able to configure remark-lint that way, and if so, does that solve your use case for now? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[btmills]

Great! Closing since this has been solved.