-
-
Notifications
You must be signed in to change notification settings - Fork 414
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
Allowing non-zero exit code in some of the commands to support pre-commit autofixing #616
Comments
I have similar thoughts on general workflow although I would not modify lint-staged. Instead I think it’s better to make 2 eslint confugs: one for local dev and one for CI. The reason is simple: not only it’s counter productive to enforce too strict config a during the pre-commit but also during the work in the IDE. Having more loose config locally could solve it. I proposed this to ESLint team but the declined proposal. I tried to work on this a while ago but due to some buggy behavior and inconsistencies in eslint APIs this wasn’t possible to do. Perhaps you want to give it another try? |
I’m not sure that moving this feature to ESlint will be easier for us than having to write To me making a few commits to a branch that I will later turn into a single squashed PR commit is essentially the same as pressing ‘save’ in my code editor while I’m still in the middle of something. The only differences are that commits are less frequent than |
I would argue with that but I’m okay with accepting there are different workflow and I don’t want the tool to be too opionated in this regard. At the same time I resist adding new config flags to the config as much as possible since it causes confusion and additional maintenance costs. To me, the solution with a custom wrapper that always exits with 0 sounds like most acceptable unless I see the community asks for this kind of behavior on a constant basis. Hope you understand my arguments. |
I totally understand your arguments and also value tools that are dead-simple on the surface. I've opened this issue to share our situation and to discover if anyone else faces a similar problem. This will probably work for us: "lint-staged": {
"**/*": [
- "eslint --fix",
- "prettier --write",
+ "suppress-exit-code eslint --fix",
+ "suppress-exit-code prettier --write",
"git add"
]
}, Just published @okonet feel free to close the issue if you want and thank you for taking part in this conversation. If anyone else seeks for suppressing exit codes, please give a shout below – this will help others know if extending |
@lkraav I tried that approach and was having trouble. With '*.{ts,js}': (filenames) => {
const cwd = process.cwd();
const relativeFilenames = filenames
.map((file) => relative(cwd, file))
.join(' ');
return [
`./node_modules/.bin/eslint --fix ${relativeFilenames}; if [ $? -eq 1 ]; then exit 0; fi`,
];
}, This is resulting in: ✖ ./node_modules/.bin/eslint --fix .lintstagedrc.js; if [ $? -eq 1 ]; then exit 0; fi:
Invalid option '-e' - perhaps you meant '-c'? I simplified the command a bit and still get this: ✖ ./node_modules/.bin/eslint --fix .lintstagedrc.js; exit 0;:
Oops! Something went wrong! :( |
I'm using pre-commit hooks to use linters as a gate. My team wanted those warnings/errors reported, but to still allow the commit through. I was struggling with Ikraav's suggestion and getting I found this solution to work well and simply:
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
if ! npx lint-staged ; then
exit 0
fi With my hook written this way, devs can always commit code, but they're also shown any linting warnings or errors that couldn't be fixed. |
I use this workaround: // lint-staged.config.js
const silent = shell => `sh -c '${shell} || exit 0'`
module.exports = {
"**/*": (files) => {
return `prettier --write --ignore-unknown ${files.join(" ")}`;
},
"*.{js,jsx,ts,tsx}": (files) => {
return silent(`eslint --fix ${files.join(" ")}`);
},
"*.{css,scss}": (files) => {
return silent(`stylelint --fix ${files.join(" ")}`);
},
}; The important points are:
|
Description
This issue is essentially a reverse of #26 🙂
We use
eslint
andprettier
as linting tools and our typicalpackage.json
looks like this:lint-staged
as a pre-commit hook.eslint
andprettier
to fix autofixable problems, but not block the commit if unfixable errors or warnings are found.**/*
everywhere is because we specify matched extensions in.eslintignore
/.prettierignore
– helps keep things DRY.This strategy does not fully work at the moment: every time
eslint --fix
finds a problem, it exits with a non-zero exit code and so the commit is blocked. This is a reasonable default behaviour, however, it is not quite what we are after.As in many other workflows, we merge PRs to
master
only whenyarn lint
passes in the CI. This means that the final diff in a PR needs to be crystal clean, however any work-in-progress commits to a new branch can include imperfections. Typical examples of acceptable issues would beconsole.log
not yet removed from the code (because of ongoing debugging) or present unused variables (because the implementation is incomplete). A precommit hook that autofixes formatting and, say, sorts imports, is useful, however a superstrict guard that blocks a commit is an obstacle to the process. We want to commit and push imperfect code to new branches as soon as possible to avoid loss of work, we just want to stay as close to perfect as automation allows us.What we can do now is to implement a wrapper around
eslint --fix
(e.g.wrapped-eslint-fix
) that would always exit with zero. It would be used like this:However, to make it easier to re-use the same trick in multiple projects, it would be nice to be able to do something like this:
New syntax is similar to what we see in eslint and webpack configs:
The potential new feature seems backwards-compatible and may support the development process in teams like ours. WDYT?
The text was updated successfully, but these errors were encountered: