Sometimes it's desired to pass an array of globs instead of just one glob to simplify negation, for example. Right now this isn't possible since glob is the object key in the JSON notation and making it an array will lead to malformed JSON.
There is a proposed solution https://github.com/okonet/lint-staged/pull/188 to create a special syntax to split strings but IMO syntax isn't very user-friendly.
In order to make this change, we'll need to update the config format which will be a breaking change. But before we do that, I'd really like to implement better config validation.
We should use https://github.com/micromatch/micromatch for this one
@okonet I think it is possible to support this feature without a backward incompatible config structure change:
[
{
"globs": ["*.js", "!*ignore.js"],
"scripts": ["eslint --fix", "git add"] // or a string
}
]
We can easily convert the current structure to this.
@sudo-suhas I like it but not sure about the name globs. Any more ideas for it?
@sudo-suhas do you want to implement this one?
not sure about the name
globs
I am okay with pattern you had suggested in #188.
do you want to implement this one?
Sure, though I would prefer coming to this after dealing with #262.
Sure, though I would prefer coming to this after dealing with #262.
I think it's much less important TBH. This one will solve real problems for many people.
pattern sounds good to me
Since it's an array, should it be patterns?
Yeah, probably patterns is better. I'm wondering if a better term can come out of this :) I still don't like patterns since it is very ambiguous. But I don't want it to be too long, too.
filters?
I'm wondering if includes and excludes would be a better choice. Or files?
My preference: filters > patterns > globs > files > includes & excludes
I changed my mind lately, the more I think about this, the more I like includes/excludes
Let's say I have a project, structured like this:
โโโ app
โ โโโ templates
โ โโโ index.js
โ โโโ utils.js
โโโ dist
โโโ cli.js
โโโ index.js
โโโ package.json
I want lint-staged to run on all .js files except for anything inside app/templates/** and dist/**
{
"lint-staged": {
"includes": ["*.js"],
"excludes": ["app/templates/**", "dist/**"],
"tasks": ["eslint --fix", "git add"]
}
}
excludes array negates what's inside the includes arrayI think it is very hard to categorically identify the better solution because on some level, they are all essentially the same. What we are discussing are very minor implementation details and that's not important. Not _very_ important any way. To me(note the transition to opinion), ['*.js', '!app/templates/**', '!dist/**'] is equally clear. And this is really what we want to pass to the library which does the filtering for us too.
Argument for the argument's sake. Don't try this at home
This is not a serious argument. I am writing this just to demonstrate that it is very hard to reason that any one of these is better:
- it's easier to read, easier to set-up
No. Not really. Now I have 2 keys to setup. Also, somebody could set up the excludes key with negated patterns(['!dist/**']).
more explicit
Hmm.. Isn't a ! equally explicit?
under the hood, IMO it's also easier for us to get this tested/implemented
Now we have 2 keys instead of 1 that we need to read and convert to a single array. On top of that we have to add the ! symbol for all the excludes globs.
@sudo-suhas technically, it's the same but I think semantics matter. No doubt excludes is much easier to read/understand at glance as looking for ! prepending patterns.
I'm in favor of includes and excludes but I'm still open for more suggestions.
Just in case you hadn't considered this: you can already handle multiple globs by using brace expansion.
The docs have a few examples using it for file extensions (e.g. "*.{js,jsx}" among others), but you can also use it for the full path: e.g. "{lib/**/*.js,dist/**/*.js}"
This won't work with the negation and it's also not intuitive.
Sure @okonet since 2 of us prefer includes and excludes, I'll change it to that. Perhaps we can continue this discussion in #273?
Most helpful comment
I changed my mind lately, the more I think about this, the more I like
includes/excludesContext
Let's say I have a project, structured like this:
I want
lint-stagedto run on all.jsfiles except for anything insideapp/templates/**anddist/**Config
Why?
excludesarray negates what's inside theincludesarray