lint-staged/lint-staged

Avoid empty commits?

borekb opened this issue · 12 comments

Maybe it's an edge case but I tested lint-staged on an example where I just mis-formatted a file to see if calling eslint --fix would do the right thing. It did – the formatting error was corrected – but it also created an empty commit. This is a different behavior compared to a scenario where I would run eslint --fix manually and then attempted to commit – Git would just tell me "no changes added to commit".

it also created an empty commit

What did create this empty commit? 🚫💩 lint-staged doesn't create commits and works as you described below: if the resulting diff is empty when there will be no-op for the commit after git add.

I had this in my config: ['eslint --fix', 'git add']. You're right that it should probably result in a no-op but it didn't in my case, I'm not sure why. Ok, I'll investigate further, it's probably not an issue with lint-staged. Thanks!

It’s definitely not the issue with 🚫💩 lint-staged since it doesn’t do commit for you.

@borekb Were you able to figure out a way around this? I've only run into this with a toy example, but I'd like to avoid any situation where the auto-fixed code will produce an empty commit.

FWIW, here's a condensed version of my use case

{
  "linters": {
    "*.{json,md,scss}": ["prettier --write", "git add"],
    "*.{ts,tsx}": ["tslint --fix", "prettier --write", "git add"]
  }
}
.foo {
  color: #fff;
}

If I change color to be uppercase, it gets fixed when I commit, but I end up with an empty commit since the file didn't change in the end.

@jcfranco In the end, we don't use --fix or git add – we simply let the checks fail and let the developer fix it. The philosophy here is that the human being should be able to see the code that is being committed but maybe that's just our thing.

@borekb Thanks for sharing!

We'll try --fix for the time being and see how it goes. I'm not sure how often this will happen since it seems the only way you’d get this is by only making auto-fixable changes.

This is the same problem when auto-fixed the code

If you're testing the eslint --fix command, by just adding some empty lines, producing auto fixable errors that don't indeed add changes to the codebase, then it makes sense to be an empty commit.

By doing so, the "changes" of the commit would be fixed when running lint-staged and then, wouldn't be any changes added to the commit.

That's the reason to have another step after running the tasks - check if it's a valid commit.

image

iiroj commented

Not sure what the issue is, but lint-staged by default prevents empty git commits (just like git itself). This can be allowed with lint-staged --allow-empty, which will then create the empty commit.

thanks

I had the same problem.

This happened to me when I tried the lint-staged scripts after filling the file with linting problems (I just added some spaces)

  "lint-staged": {
    "**/*.{js,jsx}": [
      "yarn eslint --fix",
      "prettier  --write"
    ]
  }

And lint-staged will fix the linting errors, leaving you with no modifications in the file.
This will cause the following error message:

⚠ lint-staged prevented an empty git commit.
  Use the --allow-empty option to continue, or check your task configuration

Try missing some linting errors and making a modification, such as a console.log, and everything should work properly as you expected.

hi, is there any solution to this problem without making empty git commits? If we just add spaces or change a bracket position and run lint-staged and prettier, the files are not formatted and no file gets added to git repo