The name of a processor code block is prefixed by its index

The version of ESLint you are using. 7.7.0, git blame shows this was the behavior since it was implemented in v6.

The problem you want to solve. The filename of code block found by a processor is prefixed by its index: https://github.com/eslint/eslint/blob/66442a9faf9872db4a40f56dde28c48f4d02fc7b/lib/linter/linter.js#L1298

This behavior is undocumented and counter-intuitive:

• The name filename suggests that it’s the full name of the file
• https://eslint.org/docs/developer-guide/working-with-plugins#processors-in-plugins shows the following example:

return [ // return an array of code blocks to lint
    { text: code1, filename: "0.js" },
    { text: code2, filename: "1.js" },
];

in which filename is already indexed, suggesting indexing should be handled by the processor

• https://eslint.org/docs/user-guide/configuring#specifying-processor states

Processors may make named code blocks such as 0.js and 1.js. ESLint handles such a named code block as a child file of the original file.

but block names 0.js and 1.js are never possible and combined with the example above, it suggests that the filename is the blockname

• This makes hard to configure overrides for code blocks. To override configs for specific code block, one should use "**/*.md/*_name.js"

Your take on the correct solution to problem.

1. Document the current behavior
2. Add a noPrefix (default: false) property to code block. If true, the filename is not prefixed. It’d be then up to the processor to provide unique names.

Are you willing to submit a pull request to implement this change? Yes.

[mdjermanovic]

Reopening as this issue hasn’t been triaged yet.

[eslint-deprecated[bot]]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.