feat: skip processing code blocks on specific languages like stylelint-prettier

[JounQin]

close #412, #414

Just like prettier/stylelint-prettier#22

The e2e test is a bit difficult to be added because we're supporting very long time ago versions of ESLint/Node, and such e2e test cases requires a lot of ESLint plugins to be installed which are very likely incompatible with old versions of ESLint/Node.

If you have a good idea to add e2e tests, I'll follow your advices.

[JounQin]

@BPScott Friendly ping.

[BPScott]

Heya @JounQin, sorry for the long delay.

This change and #413 both touch the same portion of code. Is the expectation that only one of them should be merged? If so which PR is preferable? I'm guessing this one as it was creating slightly later?

I was originally a bit confused by the title of this PR as we already have logic in place to skip processing code blocks when encountering languages that are not JS. But I think I understand what is happening - you're adding a new case that says we should bail out of doing any processing when both filepath !== onDiskFilepath (aka this file has been processed by a processor that provides a virtual filename) AND when the inferred parser is one of the following: [ 'babel', 'babylon' 'flow' 'typescript', 'vue', 'markdown', 'mdx' 'html'].

I think I'd have found this change a bit easier to understand if instead of adding an extra nested condition to existing code, the following block was added above line 209 (leaving the existing code unchanged):

const nonVirtualProcessorParserBlockList = ['babel', 'babylon' 'flow', 'typescript',  'vue', 'markdown', 'mdx' 'html'];
if (
  filepath !== onDiskFilepath &&
  nonVirtualProcessorParserBlockList .indexOf(prettierFileInfo.inferredParser) !== -1) {
  return;
}

Could you explain why the that list of parsers was chosen for when you're not dealing with a file created by a processor that specifies a virtual filename? I would have expected the list to be the same as when you're using virtual filenames?

---

I've been thinking for a while it might soon be time to drop older node / eslint / prettier versions. It seems like eslint/eslint#14616 is close to being merged. Perhaps I should wait till a version of eslint is released with that change present, and that can be eslint-plugin-prettier v4. That'd massively simplify a lot of the "filename on disk" logic.

[JounQin]

@BPScott Thanks for reply finally first.

This change and #413 both touch the same portion of code. Is the expectation that only one of them should be merged? If so which PR is preferable? I'm guessing this one as it was creating slightly later?

They are both valid, while #413 only add support for @graphql-eslint, and this PR doesn't touch that. If you want, I can merge them, but I prefer to separate the two PRs personally because they are different.

Could you explain why the that list of parsers was chosen for when you're not dealing with a file created by a processor that specifies a virtual filename? I would have expected the list to be the same as when you're using virtual filenames?

I just want to keep compatibility and borrowed the list from stylelint-prettier. Maybe the list can be updated. 🤣

The original list is used for some legacy ESLint plugins as I commented:

// The following list means the plugin process source into js content
// but with same filename, so we need to change the parser to `babel`
// by default.

// Related ESLint plugins are:
// 1. `eslint-plugin-graphql` (replacement: `@graphql-eslint/eslint-plugin`)
// 2. `eslint-plugin-markdown@1` (replacement: `eslint-plugin-markdown@2+`)
// 3. `eslint-plugin-html`

[JounQin]

I've been thinking for a while it might soon be time to drop older node / eslint / prettier versions. It seems like eslint/eslint#14616 is close to being merged. Perhaps I should wait till a version of eslint is released with that change present, and that can be eslint-plugin-prettier v4. That'd massively simplify a lot of the "filename on disk" logic.

That would just help to remove getOnDiskFilepath inside, nothing else, doesn't it? I think it is good to support old version of ESLint if it just requires a simple function. But of course, dropping older node/eslint/prettier versions are great too. I'm fine with that. v4 for BREAKING CHANGE like this PR is good.

[BPScott]

They are both valid, while #413 only add support for @graphql-eslint, and this PR doesn't touch that. If you want, I can merge them, but I prefer to separate the two PRs personally because they are different.

OK, that makes sense - I see that @graphql-eslint handles graphql files but uses virtual filenames (where as eslint-plugin-graphql does not use virtual filenames)

The original list is used for some legacy ESLint plugins as I commented:

I don't think legacy is the right word here. It is totally valid for eslint plugins to choose not to use virtual filenames. I'd absolutely prefer that they did use virtual filenames, but I don't think there's anything that suggests not specifying a filename going to be unsupported by eslint in the future.

I just want to keep compatibility and borrowed the list from stylelint-prettier. Maybe the list can be updated. 🤣

I think it will need to be updated. THe list in stylelint-prettier is designed to removed non-css file types but for eslint-plugin-prettier we'd want to remove non-js file types - for instance currently this code does an early return when the parser is babel which means all JS files will be skipped! I thiiiiink it ends up being the same list as the current parser block list, but I'll need to think about that a bit more.

That would just help to remove getOnDiskFilepath inside, nothing else, doesn't it?

There are a few other simplifications too. e.g. supporting only prettier v2 means the supportBabelParser check can be removed as that will be always true (it is only false in prettier <1.16). It will also make writing e2e tests easier as we won't have to handle all those old versions as you mentioned in your original post.

[JounQin]

I don't think legacy is the right word here. It is totally valid for eslint plugins to choose not to use virtual filenames. I'd absolutely prefer that they did use virtual filenames, but I don't think there's anything that suggests not specifying a filename going to be unsupported by eslint in the future.

Oh, sorry, but I mean: eslint-plugin-graphql should be replaced by @graphql-eslint, eslint-plugin-markdown@1 has been upgraded to eslint-plugin-markdown@2+ which uses virtual filenames, and eslint-plugin-html wants to do like so too: BenoitZugmeyer/eslint-plugin-html#139.

for instance currently this code does an early return when the parser is babel which means all JS files will be skipped

That's not true, they are just skipped when *-in-js, for example, graphql-in-js like #413 (comment).

The original js/ts file will still be processed because filepath === onDiskFilepath. That's why we should treat virtual filename and physical filename separately.

There are a few other simplifications too. e.g. supporting only prettier v2 means the supportBabelParser check can be removed as that will be always true (it is only false in prettier <1.16). It will also make writing e2e tests easier as we won't have to handle all those old versions as you mentioned in your original post.

Right, I was saying your mentioned ESLint PR only adds getPhysicalFilename method, that does not make many senses. But for e2e tests, I'm glad to upgrade all versions.

[BPScott]

That's not true, they are just skipped when *-in-js, for example, graphql-in-js like #413 (comment).

I don't think processors needed to do anything for *-in-js as you've described - when given a JS file ESLint doesn't need to run a processor over it - you don't need to transform file content into valid JS if it is already JS! Processors only kick in when you're transforming a non-js file into valid JS. e.g. turning a .graphql into JS by wrapping it in a tagged template literal, or extracting fenced code blocks out of an .md file.

These processors are only ever going to create filenames like myfile.graphql/foo.js

I agree with the sentiment in #413 (comment) and prettier/stylelint-prettier#22 that eslint-plugin-prettier shouldn't bother running prettier over these fragments of a file: If you're this interested in prettier then you probably want to run prettier over the rest your .graphql / .mdx etc file to to get it fully formatted. Thus it seems pointless to duplicate that work of running prettier within eslint.

[JounQin]

I don't think processors needed to do anything for *-in-js as you've described - when given a JS file ESLint doesn't need to run a processor over it - you don't need to transform file content into valid JS if it is already JS! Processors only kick in when you're transforming a non-js file into valid JS. e.g. turning a .graphql into JS by wrapping it in a tagged template literal, or extracting fenced code blocks out of an .md file.

@graphql-eslint is also processing .js files for gql tags. What means:

// test.js

const test = gql`
  # content
`

See also: https://github.com/dotansimha/graphql-eslint#configuration

And also @angular-elsint lints templates in .component.ts too.

See also https://github.com/angular-eslint/angular-eslint/blob/master/packages/eslint-plugin-template/src/processors.ts#L259

[rtrembecky]

just noticed a typo so bringing it up 😅

[BPScott]

I don't think processors needed to do anything for *-in-js as you've described - when given a JS file ESLint doesn't need to run a processor over it - you don't need to transform file content into valid JS if it is already JS! Processors only kick in when you're transforming a non-js file into valid JS. e.g. turning a .graphql into JS by wrapping it in a tagged template literal, or extracting fenced code blocks out of an .md file.

@graphql-eslint is also processing .js files for gql tags. What means:

// test.js

const test = gql`
  # content
`

See also: https://github.com/dotansimha/graphql-eslint#configuration

And also @angular-elsint lints templates in .component.ts too.

See also https://github.com/angular-eslint/angular-eslint/blob/master/packages/eslint-plugin-template/src/processors.ts#L259

Yep sure but what's the result of context.getFilename(); in these cases? I would expect that to be the filename that matches the filename on disk that is already a JS file - test.js rather than some virtual filename test.js/_0.graphql/0.js

[JounQin]

Yep sure but what's the result of context.getFilename(); in these cases? I would expect that to be the filename that matches the filename on disk that is already a JS file - test.js rather than some virtual filename test.js/_0.graphql/0.js

For @graphql-eslint, it's test.js/0_document.graphql(https://github.com/dotansimha/graphql-eslint/blob/master/packages/plugin/src/processors/code-files.ts#L36) and it has a .graphql parser: https://github.com/dotansimha/graphql-eslint/blob/master/packages/plugin/src/parser.ts#L16

For @angular-eslint, it's test.ts/0_inline-template-0.component.html(https://github.com/angular-eslint/angular-eslint/blob/master/packages/eslint-plugin-template/src/processors.ts#L221) and it has a .html parser: https://github.com/angular-eslint/angular-eslint/blob/master/packages/template-parser/src/index.ts#L179

[JounQin]

@BPScott Any news? It's already two months after our last conversation...

[BPScott]

Heya @JounQin. Thank you for your patience. As you've saw I've found it hard to find time for this project thanks to personal stuff.

I wanted to spend some time understanding how processors interact with tests and if getFilename stuff made any of that easier, I managed a bit but didn't find any easy answers. I see you've pushed for a bunch of improvements in eslint/eslint#14616 and eslint/eslint#14800. Thank you for doing all of that, hopefully eslint adds eslint/rfcs#31 at some point to make the e2e testing of all this a lot easier.

I've merged #413 and have released it as v3.4.1. Would you be able to rebase this PR atop latest master. When you originally opened this PR i wasn't sure how to reconcile the the conflicting changes in #413 and this PR.

I'll try and drop the old versions of eslint in a major version at some point, which should let us leverage getPhysicalFilename() and simplify some of this.

[JounQin]

Thanks @BPScott

No worry, I've already had a rebased branch locally, I'll push it when I'm free today.

Before eslint/rfcs#31, we can still use our own physicalFilename, or only use it on testing for workaround.

[JounQin]

@BPScott Already rebased!

[JounQin]

@BPScott I just added ESLint API based fixtures support at https://github.com/prettier/eslint-plugin-prettier/pull/415/files#diff-79377e9ab524ea5107fe58032bf72dae0a8eee2c210275404d346a98908b2b78R258-R297

Maybe snapshot based test cases would be better.

[JounQin]

@BPScott Any news again?

[dimaMachina]

@BPScott any news? 🙏

[shaneog]

I just ran into this issue.

@BPScott Is there any issue with proceeding with this?
@JounQin - would you be able to fix the conflicts if @BPScott has no issues?

[JounQin]

Rebased.

It becomes a bit ridiculous since the PR has been raised for more than one year!

I'll have to publish a fork instead later...

[JounQin]

Just released @rxts/eslint-plugin-prettier@4.1.0, source codes at https://github.com/JounQin/eslint-plugin-prettier/tree/fork-release, you can use

# yarn
yarn add -D eslint-plugin-prettier@npm:@rxts/eslint-plugin-prettier@^4.1.0

# pnpm
pnpm add -D eslint-plugin-prettier@npm:@rxts/eslint-plugin-prettier@^4.1.0

# npm
npm i -D eslint-plugin-prettier@npm:@rxts/eslint-plugin-prettier@^4.1.0

Then it will just work the same as before with this feature enabled.

[dimaMachina]

@BPScott please merge this PR

[JounQin]

https://github.com/prettier/eslint-plugin-prettier/releases/tag/v4.1.0

eslint-plugin-prettier@v4.1.0 has been released!