eslint / eslint-plugin-markdown

Lint JavaScript code blocks in Markdown documents
MIT License
369 stars 59 forks source link

Configure file name based on block meta #226

Open JoshuaKGoldberg opened 8 months ago

JoshuaKGoldberg commented 8 months ago

Some projects use ESLint overrides to run different lint rules on files based on their file name. It'd be nice if the meta for a code block was respected in some way to retrieve file name, so that overrides can be used for code blocks too.

Right now, eslint-plugin-markdown always uses a name in this format: https://github.com/eslint/eslint-plugin-markdown/blob/4d9f36f5c5fd1b5d3b1957913118cd76a92750f2/lib/processor.js#L299

Proposal: use a file name described by the code block's meta instead of index when possible?

Pending investigation: I don't know that there's a standard way to describe that file name. https://astexplorer.net/#/gist/0cce3ae28ac100aa5d78e3a88fdbf15e/e79a0e179def1bad1d8d7771f789709177c28a9a shows that the following codeblock's meta is the raw string "example abc=def" in remark:

```javascript example abc=def
console.log('!');
```

Context/example: in https://github.com/JoshuaKGoldberg/create-typescript-app, *.json files except package.json files have jsonc/sort-keys run: https://github.com/JoshuaKGoldberg/create-typescript-app/blob/76a75186fd89fc3f66e4c1254c717c28d70afe0d/.eslintrc.cjs#L94. In https://github.com/JoshuaKGoldberg/create-typescript-app/pull/986/files#diff-cc908ca4b57d59e44123c8b13deee7af64523aa40e21f69f11d4c604af276ff6R19 a codeblock intended to be a package.json is create-typescript-app/docs/FAQs.md/0_0.jsonc even with the meta. I had to manually disable the lint rule. I'd have preferred to instead extend the ESLint config's override to something like **/package.json.

I think this is a separate ask from #208. Not sure.

nzakas commented 8 months ago

Proposal: use a file name described by the code block's meta instead of index when possible?

How would we guarantee a unique filename for each chunk? That's the main purpose of using the index.

JoshuaKGoldberg commented 8 months ago

Hmm yes - so, 0-0-package.json, etc.?

nzakas commented 8 months ago

Can you flesh out what exactly it is that you're requesting here? Should people be able to completely override the filename? (Like, if a block is js, should people be able to create a file that doesn't end in .js?) What is it you're proposing as the syntax for doing this?

JoshuaKGoldberg commented 8 months ago

Should people be able to completely override the filename?

On second thought: I think having it directly take the file name would be preferable. If an override wants to be configured for just package.json files (not *-package.json), I think there should be a way for the code block to specify that file name.

So I'm suggesting:

  1. Allow a code block to specify its file name with ```js path="name.ext"```
    • Paths: deep names may be specified, such as path="example-1/package.json"
    • Uniqueness: if a code block repeats a previously used path, eslint-plugin-markdown reports a parsing error
  2. Directly passing that path as the filename in the processor
    • If this isn't yet allowed, this would be blocked on me/us filing a feature request on ESLint core

(Like, if a block is js, should people be able to create a file that doesn't end in .js?)

I would be satisfied with ignoring block.lang if a path is specified. It'd be difficult to handle language variants such as .jsonc and .mts.

nzakas commented 8 months ago

Allow a code block to specify its file name with js path="name.ext"

Is this already a convention that exists?

You've shared bits and pieces in this discussion, but I'd like to see a complete proposal, mini-RFC style, that explains exactly what you're envisioning, including how such a path would be augmented with an index (or not, but then how do we ensure unique filenames?).

JoshuaKGoldberg commented 7 months ago

Sorry for the delay - sent #230 so we can chat in a bit more structured of a format. I tried pulling in references to related ecosystem projects but doubt I got all the potentially relevant ones.

nzakas commented 7 months ago

Thanks. We are pretty deep in v9 work right now, so this may end up sitting for a while until we can get our heads above water.