Disregard default ignores when ignoreFiles is used

[bzang]

Describe the issue. Is it a bug or a feature request (new rule, new option, etc.)?

Target files located in any node_modules folder are ignore even when I specifically want to lint them.

Which rule, if any, is this issue related to?

N/A

What CSS is needed to reproduce this issue?

N/A

What stylelint configuration is needed to reproduce this issue?

N/A

Which version of stylelint are you using?

7.7.1

How are you running stylelint: CLI, PostCSS plugin, Node API?

CLI with stylelint "packages/node_modules/**/*.css" --config .stylelintrc.yml -i node_modules

Does your issue relate to non-standard syntax (e.g. SCSS, nesting, etc.)?

No

What did you expect to happen?

All files with extension css in the packages/node_modules folder to be linted

What actually happened (e.g. what warnings or errors you are getting)?

Nothing happens

Possible Solutions

• allow ignorePath to overwrite the default ignore
• expose alwaysIgnore as a config option that defaults to the current value (https://github.com/stylelint/stylelint/blob/master/lib/isPathIgnored.js#L28)
• change alwaysIgnore to only ignore root node_modules directory.

[alexander-akait]

@bzang why you need linting in node_modules? it is quite specific and would like to hear real use case

[bzang]

@evilebottnawi. Our project uses the alle pattern https://github.com/boennemann/alle, which is a monorepo pattern that places all packages in a packages/node_modules folder. This allows node to traverse up the file tree to find modules that are in the repo and make them usable as imports. As it stands, even if we point stylelint to a specific file, the file does not get linted due to the hard coded alwaysIgnore values.

[jeddy3]

@bzang Interesting use case. Do you encounter the same issue when using eslint as they also ignore the node_modules directory by default?

[bzang]

@jeddy3, eslint actually only ignores the base node_modules directory. That's why they specify /node_modules/*. Any other node_modules directory isn't automatically ignored.
I think this is a reasonable setup since the root node_modules directory is generally where npm installs everything.

[jeddy3]

@bzang Thanks for looking into it.

only ignores the base node_modules directory.

Funnily enough, we're following the lerna monorepo approach on my current project.

packages/
  package_1/
    node_modules/
  package_2/
    node_modules/

So, having stylelint ignore any file with node_modules somewhere in the path is beneficial to us.

Having said that, as stylelint doesn't have a option to disable the default ignores, perhaps they should be more permissive? @stylelint/core Should we change this default behaviour for 8.0.0?

[bzang]

@jeddy3, yea we were using Lerna before switching over to alle, and stylelint worked great!

I believe that the ignoreFiles config can already deal with additional ignore paths. So passing something like packages/**/node_modules/* should handle the Lerna use case.

It makes sense to have node_modules as a default ignore because that is a very common use case, but incorporating an override would add a lot more flexibility.

[alexander-akait]

@jeddy3 maybe if not passed ignoreFiles patterns use default, if passed use only their?

[BradleyStaples]

I was just looking into this as well, as my company uses both /node_modules and /src/node_modules in our apps because of our internal framework. Any CSS files in /src/node_modules/... are showing in the list of sources in the console output, but have (ignored) after them.

I tried setting ignoreFiles to [], '', null, '!/src/node_modules/**/*.scss', and ['!/src/node_modules/**/*.scss'] with no changes in behavior.

Green file was successfully linted, gray file was ignored.

👍 for doing like ESLint does (which we also use), where the base /node_modules/ gets ignored but not any nested node_modules directories.

[alexander-akait]

@jeddy3 i think we should change logic in the 8.0.0 release for nested node_modules directories
Our code:

stylelint/lib/isPathIgnored.js

Line 7 in b5145a1

const alwaysIgnoredGlobs = [ "**/node_modules/**", "**/bower_components/**" ]

Eslint code: https://github.com/eslint/eslint/blob/616611afe19da5380344042fc73c7b91e59375cc/lib/ignored-paths.js#L32

[jeddy3]

i think we should change logic in the 8.0.0 release for nested node_modules directories

I think so too.

Releasing 8.0.0 is a bit away yet, and so what are our options for getting @bzang & @BradleyStaples up and running in the interim? Would a no-default-ignore option suffice here?

[alexander-akait]

@jeddy3 no-default-ignore sgtm

[jeddy3]

@davidtheclark Always keen for your input and nod of approval when adding options to the CLI. Any objection to this option, or shall I open it out to contribution?

[davidtheclark]

Ugh. Sticky situation. no-default-ignore really bugs me, and I feel weird about including weird logic for such a weird use-case with nested node_modules. Next we'll get an issue with people complaining because their nested node_modules are being linted — which is totally counterintuitive because other node_modules (non-nested) are being automatically ignored.

Here's what I'd favor: Make ignoreFiles have a regular old default of **/node_modules/**/* — all node_modules. A regular old default is just overridden when you provide a value — so that's what would happen. If you want to ignore other files, you include your own ignore pattern, including whatever node_modules ignores you want. @evilebottnawi suggested the same above, I believe.

[alexander-akait]

@davidtheclark right, perhaps this logic is best suited to solve the issue

[jeddy3]

A regular old default is just overridden when you provide a value — so that's what would happen. If you want to ignore other files, you include your own ignore pattern, including whatever node_modules ignores you want.

SGTM, thanks for chiming in. This change of behaviour will be for 8.0.0, right? As some users might be relying on the fact that node_modules is always ignored regardless of whether they have specified their own pattern or not.

[davidtheclark]

This change of behaviour will be for 8.0.0, right

Yeah, absolutely.

[BradleyStaples]

Is there a rough guess for when 8.0.0 will be out? I'm going to have to find some solution to lint our files at work and I'm likely unable to wait for a long time, so I'll need to evaluate my options.

[jeddy3]

Is there a rough guess for when 8.0.0 will be out?

Probably a few weeks as there's quite a bit left to do. You can help us speed up the process by tackling some of the 8.0.0 milestone issues.

[bzang]

Thanks for hopping on this everyone. I definitely agree with @davidtheclark's solution. That seems to be the most sustainable and also similar to how other tooling environments like webpack deal with overrides and ignores. Will lend a hand at the 8.0.0 milestone issues to speed this along.

[davidtheclark]

Closed by #2464.