Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow glob exclusions #5

Closed
okonet opened this issue Apr 15, 2016 · 7 comments · Fixed by #14
Closed

Allow glob exclusions #5

okonet opened this issue Apr 15, 2016 · 7 comments · Fixed by #14

Comments

@okonet
Copy link
Collaborator

okonet commented Apr 15, 2016

Some projects commit build (dist) files to the repository. Usually, the syntax of these generated files is out of the scope of linters. But ATM all files that matches the glob pattern will run against linters.

Ideally we want *-staged tasks to be configured the same way as normal linter tasks.

But this might require a major rewrite and switch to the Node from CLI.

@davidhund
Copy link

@okonet I've run into exactly this issue: my generated global.min.css does break linting rules, so I'd like to exclude it. My current config is:

  "lint-staged": {
    "gitDir": "../../../../../../../../",
    "linters": {
      "*.js": "eslint",
      "*.css": "stylelint"
    }
  }

so I'd like to exclude specific files (e.g. "*.css, !global.min.css": "stylelint", but this does not seem to work.

Any tips?

@okonet
Copy link
Collaborator Author

okonet commented Nov 16, 2016

  1. You can use globs in the lint-staged config. See https://github.com/isaacs/minimatch documentation.
  2. I'd recommend to add minified files to global .eslintignore and .stylelintignore. By doing so you'll have the config shared between all runs not just in lint-staged.

@davidhund
Copy link

davidhund commented Nov 16, 2016

Thanks again @okonet — I've looked into the minimatch globbing but did not found it very intuitive. Got it to work with "[!Public]*.css": "stylelint" (exclude files from Public output folder).

However, using a .stylelintignore file is a much more elegant solution. Thanks again!

@jharris4
Copy link

jharris4 commented May 2, 2017

Ouch, this burned me too. I was trying to use !(node_modules|dist|lib|es)**/*.js for my pattern. And the minimatch docs say:

If the pattern starts with a ! character, then it is negated. Set the nonegate flag to suppress this behavior, and treat leading ! characters normally. This is perhaps relevant if you wish to start the pattern with a negative extglob pattern like !(a|B). Multiple ! characters at the start of a pattern will negate the pattern multiple times.

I'm trying to see if there's a way to work around this with a different pattern, but otherwise I'll have to think about making a PR to support passing the nonegate flag to minimatch somehow...

@tnrich
Copy link
Contributor

tnrich commented Jun 9, 2017

Hey there @okonet @jharris4 @davidhund ,

I was naively trying to do something like:

"lint-staged": {
    "src/**/*.js server/src/**/*.js, !server/src/models/**/*.js ": [
      "prettier --write",
      "git add"
    ]
  }

but it doesn't seem to be working. Do I need to do something else to get the functionality I need?

Maybe you could use https://yarnpkg.com/en/package/multimatch instead of minimatch to support what I'm trying to do?

Thanks!

@okonet
Copy link
Collaborator Author

okonet commented Jun 9, 2017

Good suggestion. Do you mind creating a PR for that?

@nikhil618
Copy link

Hey there @okonet @jharris4 @davidhund ,

I was naively trying to do something like:

"lint-staged": {
    "src/**/*.js server/src/**/*.js, !server/src/models/**/*.js ": [
      "prettier --write",
      "git add"
    ]
  }

but it doesn't seem to be working. Do I need to do something else to get the functionality I need?

Maybe you could use https://yarnpkg.com/en/package/multimatch instead of minimatch to support what I'm trying to do?

Thanks!

For anyone who stumbles upon this issue like me it now supports glob match but uses micromatch now read this post I added for the fix.
https://stackoverflow.com/a/57981925/1221731

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

5 participants