feat: support .stylelintignore file

[BlackHole1]

This PR contains a:

• bugfix
• new feature
• code refactor
• test update
• typo fix
• metadata update

Motivation / Use-Case

#105

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Black-Hole (bd42af4)

[codecov]

Codecov Report

Merging #257 (dc97afc) into master (79fb44d) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #257   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            8         8           
  Lines          219       227    +8     
  Branches        51        53    +2     
=========================================
+ Hits           219       227    +8     

Impacted Files	Coverage Δ
src/index.js	100.00% <100.00%> (ø)
src/utils.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 79fb44d...dc97afc. Read the comment docs.

[alexander-akait]

In my option, stylelint should have API to do it, otherwise they can change logic and it will be problem for us, we need ping somebody from stylelint here

@ybiquitous @jeddy3

Any advices? I haven't worked directly with api for a long time, so maybe I'm missing something, thanks

[ricardogobbosouza]

@alexander-akait You're right
I just did a test and stylelint handles it perfectly.

[ricardogobbosouza]

Hi @BlackHole1
Better let stylelint handle it itself

[BlackHole1]

hi @ricardogobbosouza , I have an example to describe why this should be done.

Please reopen this pr and I'll submit a gist/repo later to explain why I'm doing this.

[ricardogobbosouza]

@BlackHole1 Please share a repository where this issue occurs. So I can reanalyze the PR

[BlackHole1]

okey

[BlackHole1]

repo: https://github.com/BlackHole1/stylelint-webpack-plugin-PR-257

cc: @ricardogobbosouza @jeddy3

[BlackHole1]

On its own, it is fine to decouple the logic of the plugin from stylelint itself. But based on the user's experience, it is better for the user that we have proper coupling.

Since this plugin is for stylelint, our handling of it will make the whole behaviour more uniform.

From a developer's (user's) point of view, I don't think many people want to maintain two sets of essentially the same thing

[BlackHole1]

For example, I'll use vscode-stylelint as an example: https://github.com/stylelint/vscode-stylelint/blob/59be6cc89d04ed5efaf122c838ac31003d15de4f/src/extension/extension.ts#L38

This plugin recognises .stylelintignore, not stylelint-webpack-plugin -> exclude

[alexander-akait]

Ideally stylelint should iself ignore them (i.e. loader .stylelintignore and do not report warnings/errors for these patterns), maybe we forget something to setup?

[BlackHole1]

In eslint, a warning will be reported instead of an error

[BlackHole1]

In stylelint, this error is expected. see:
https://github.com/stylelint/stylelint/blob/060310cfd6383175ee06fe4d15aee27a4e202671/lib/standalone.js#L261

cc: @alexander-akait

[BlackHole1]

Perhaps I should submit a PR to stylelint to add an option to control whether not found file errors are reported?

or use allowEmptyInput ?

[alexander-akait]

I think it s good way, let's open an issue and discuss it, I'm not against it, I just would like to avoid duplicate code and found valid way to solve it

[ricardogobbosouza]

@BlackHole1
In my opinion we should return the same as stylelint, after all this is a plugin for it.

In your https://github.com/BlackHole1/stylelint-webpack-plugin-PR-257 repo, if we run stylelint src/**.css it returns the same error as npx webpack ./src/index.js --mode=development

We shouldn't treat it differently.

And if we don't have stylesheets to lint, it doesn't make sense to have the plugin configured, don't you think?

[BlackHole1]

@BlackHole1 In my opinion we should return the same as stylelint, after all this is a plugin for it.

In your https://github.com/BlackHole1/stylelint-webpack-plugin-PR-257 repo, if we run stylelint src/**.css it returns the same error as npx webpack ./src/index.js --mode=development

We shouldn't treat it differently.

And if we don't have stylesheets to lint, it doesn't make sense to have the plugin configured, don't you think?

I agree:

stylelint src/**.css it returns the same error as npx webpack ./src/index.js --mode=development

But this is because I only have one css file, if I had two css files then the situation would be different

[BlackHole1]

Oooh, Sorry. Their behaviour is consistent

[BlackHole1]

I'm sorry I didn't add some details. I've only just recalled the full details because it's been a bit too long. Please wait a moment while I refine the entire description of the problem.

[ricardogobbosouza]

If I have 2 or more files and they are all ignored then I don't have any.

But if I have at least 1 valid file, it will go through lint normally.

[BlackHole1]

The problem is with watch.
I've just pushed the code, you can revisit it https://github.com/BlackHole1/stylelint-webpack-plugin-PR-257

When a user starts watch and modifies an ignored css file, they will get an error

[ricardogobbosouza]

Ok. When watching we have this problem

[BlackHole1]

I've come up with an idea to get around this error by passing in the allowEmptyInput parameter when the current mode is watch.

[ricardogobbosouza]

Eu tive uma ideia para contornar esse erro passando

But I think it's not the most ideal

[BlackHole1]

Eu tive uma ideia para contornar esse erro passando

But I think it's not the most ideal

Oh? Can you describe your reasoning?🧐

Because it seems to me that this is a way to be consistent with stylelint without having to deal with .stylelintignore

Can you describe, ideally, the situation? We can always discuss how to do that. 🙇

[ybiquitous]

Hi there, I'm a maintainer of Stylelint. ✋🏼

Maybe, stylelint/lib/utils/getFileIgnorer.js may be useful in such a case, though the module is internal and its return type is one of the ignorer package.

Of course, you can also open an issue to suggest a new API for the case. Here are the discussion issues about new APIs:
https://github.com/stylelint/stylelint/issues?q=is%3Aissue+is%3Aopen+Expose+

[ricardogobbosouza]

@BlackHole1
#257 (comment)

My thought is, that if the file is skipped, it shouldn't go through lint even in watch mode.
The stylelint is running unnecessarily in this case

[BlackHole1]

Perhaps we should export stylelint/lib/utils/getFileIgnorer.js function, and use?

[ricardogobbosouza]

The stylelint could have in its api a function stylelint.isFileIgnored(path)

[BlackHole1]

The stylelint could have in its api a function stylelint.isFileIgnored(path)

Good idea. I'll submit a PR to stylelint later