Lint-staged: Support for prepush as well

[bguiz]

Firstly, thanks - this is an awesome library!

As the name of this lib implies, it passes the names of the files - that are currently staged for git commit - to the configured linters. This it works really well to this effect, and is best employed in a git precommit hook.

However, I feel that this lib can be useful beyond this use case, and work quite well to power a git prepush hook as well. In order for it to power this use case, the list of files to pass to the configured linters should be different: Instead of staged files, have all the files that have been added since between the current branch and its parent branch.

What are your thoughts on this?

[sudo-suhas]

This is my personal opinion but this might be an unnecessary optimisation. I would rather run the entire test suite on CI.

[bguiz]

Yeah @sudo-suhas, I agree that on CI the entire test suite should be run.

OTOH, if I were to do that every time I push to a git remote, that would slow down my development, so running filtered tests is definitely a use case here.

In any case, what I'm raising here is not whether to filter, but rather:

• instead of filtering using this criteria (staged git changes),
• use this other criteria instead (committed git changes).

[okonet]

I wrote my thoughts on this here: https://github.com/okonet/lint-staged/issues/150#issuecomment-297692665

@bguiz do you want to try implementing this and we'll see if this is a good idea?

[bguiz]

So, I'd say it could be an additional option gitCmd that would get you the list of files. So for staged files it would be something like git diff-index --cached --name-only HEAD and for all changed you'll run it without --cached.

@okonet yup, allowing you to specify a custom gitCmd in the options seems like a great idea. It'll solve the problem that I have at hand, plus also solve the issue of miscellaneous requests that many other devs will have when they wants a list of files that have x instead of y.

The main catch here is that it since we don't know what command is being used here, there'll need to be validation of its output, plus consider the security ramifications of allowing any arbitrary command to be run. Since this is a dev tool (and isn't user facing), I'm not so worried about the latter. The former would still be worth considering though.

[okonet]

Also, considering #277 I might not proceed with this one.

[bguiz]

So no custom gitCmd then? 😟

[okonet]

Probably not. This needs more validation. I want this tool to be focused on a single task rather than trying to do everything.

[cakeinpanic]

take a look at this script, it seems to be doing what you need
https://github.com/cakeinpanic/polite-linter

[turadg]

This needs more validation

I share @bguiz 's wish to lint on prepush instead of precommit. My hook does a lot now and takes some time to run, time that slows down each commit. And when there's an error it's awkward in Github Desktop I sometimes use for patches.

The purpose of what I run in the hooks is to catch problems sooner than the CI, so all I really need is to check what I'm pushing.

I want this tool to be focused on a single task rather than trying to do everything.

@okonet would you be comfortable with someone forking this to handle the prepush use case? E.g. like https://github.com/clakech/lint-committed

(@cakeinpanic , your polite-linter does not allow for the other lint logic I have)

[okonet]

It’s open source. You’re free to do whatever works best for you :)

What about supporting multiple configs instead? Or having a config format that would allow multiple filters?

[okonet]

Let’s close this issue and move the discussion to #150

[Restuta]

@okonet I think #150 is not the same issue. pre-push would require linting of all files on the current branch that are different from origin/[current-branch]

[okonet]

I think it is similar. What you’re asking is a customizible command for git to determine the file list. That will allow both use cases.