Allow only formatting code snippets in markdown, not the markdown file itself

[antfu]

What version of eslint are you using?

8.55.0

What version of prettier are you using?

3.1.0

What version of eslint-plugin-prettier are you using?

5.0.1

Please paste any applicable config files that you're using (e.g. .prettierrc or .eslintrc files)

https://stackblitz.com/edit/node-mhr6sb?file=README.md,eslint.config.js

What source code are you linting?

See the Stackblitz link above

What did you expect to happen?

With fine-grained files option in the flat config, Prettier should be able to format virtual files created by eslint-plugin-markdown to format the code snippet in Markdown.

What actually happened?

There is a hard-coded logic to ignore any virtual file created in markdown as well as a few other extensions:

eslint-plugin-prettier/worker.js

Lines 129 to 152 in 1882a36

	} else {
	// Similar to https://github.com/prettier/stylelint-prettier/pull/22
	// In all of the following cases ESLint extracts a part of a file to
	// be formatted and there exists a prettier parser for the whole file.
	// If you're interested in prettier you'll want a fully formatted file so
	// you're about to run prettier over the whole file anyway.
	// Therefore running prettier over just the style section is wasteful, so
	// skip it.
	const parserBlocklist = [
	'babel',
	'babylon',
	'flow',
	'typescript',
	'vue',
	'markdown',
	'html',
	'mdx',
	'angular',
	'svelte',
	];
	if (parserBlocklist.includes(/** @type {string} */ (inferredParser))) {
	return;
	}
	}

I consider it a valid default as it might cause nested formatting when users enable eslint-plugin-prettier to all files.

But with the new Flat Config, you are able to only enable certain rules with certain options for specific types of files. In the case where we don't config Prettier to format the parent markdown, treating the virtual files as normal formattable code should be allowed.

Proposed solutions

I imagine we could introduce a flag to opt-out of this hard-coded logic, and give the control of ignoring a file to users.

I made a simple implantation, adding a new config called fullControl: a333607

Let me know if you have a better idea/naming. Thanks!

[JounQin]

I'm not sure to understand, markdown files are formatted by prettier itself already?

You can use https://github.com/mdx-js/eslint-mdx/tree/master/packages/eslint-plugin-mdx to enable linting markdown files via eslint already.

[antfu]

With Flat Config, you can only enable Prettier to format on specific type,

export default [
{
  files: ['**/*.css'], // <-- this
  plugins: {
    prettier: pluginPrettier,
  },
  languageOptions: {
    parser: parserPlain,
  },
  rules: {
    'prettier/prettier': ['error', { parser: 'css' }],
  },
}
]

In my case I only want Prettier to take care all CSS in the pipeline but not Markdown itself.

[JounQin]

In my case I only want Prettier to take care all CSS in the pipeline but not Markdown itself.

I don't think this is how prettier works.

[antfu]

Prettier is a formatter that can even format a string in the memory, right? I don't see any reason I can't use Prettier to only format a selection of files (or virtual files).

[JounQin]

It can do it, but why it should do it?

cc @BPScott

[antfu]

I don't understand what we are even debating. Do you mean that the only way Prettier should work is to format all files?

[JounQin]

Yes. It should format the whole file, not all files, sorry.

Prettier is an opinionated code formatter

I'd like to listen from @BPScott at the same time.

[antfu]

Just for context, eslint-plugin-markdown will create a virtual file for each code snippet, and allow other plugins to treat them as a normal file.

For ./README.md

Markdown Test

```css
.code { color: red }
```

The virtual file will be ./README.md/0.css (which matches the **/*.css glob).

.code { color: red }

Which from the plugin point of view, it's a single file not a part of the file.

eslint-plugin-prettier's current behavior is a bit coupled with the filesystem and is not 100% agnostic (like you can turn off prettierrc, but .getFileInfo is mandatory with hard-coded logic).

From your words, I feel that currently this plugin is more like an "ESLint integration for Prettier, the opinionated formatting CLI Tools" over an "ESLint plugin using Prettier as the opinionated code formatter" -- Which is also fair, I'd respect that if you position it that way. "Opinionated" is an easy word to close the door I guess, where I see there might still be many interesting possibilities we could explore.

[JounQin]

I was referencing eslint-plugin-mdx, it supports markdown at the same time, not eslint-plugin-markdown.

---

"Opinionated" is an easy word to close the door I guess, where I see there might still be many interesting possibilities we could explore.

That's why I said:

I'd like to listen from @BPScott at the same time.

[antfu]

eslint-plugin-mdx looks cool and I'd love to give it a try. Tho I feel it's not really related to this issue. What I want to do is fill the gap that ESLint lacks support for some file formats like CSS. I imagine with eslint-plugin-mdx I'll be able to format markdown but the CSS code snippet will still remain untouched right?

[JounQin]

I'll be able to format markdown but the CSS code snippet will still remain untouched right?

Code snippets linting by eslint-plugin-mdx is powered by eslint-plugin-markdown.

What means you can already achieve what you want already.

[JounQin]

What I want to do is fill the gap that ESLint lacks support for some file formats like CSS.

Maybe you want https://github.com/ota-meshi/eslint-plugin-css

In the feature, ESLint will not only focus on JavaScript ecosystem, it would be very easy to create a language plugin for ESLint, see aslo stylelint/stylelint#6593