-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Husky pre-commit fails with code 1 (error) #1014
Comments
Similar issues with VS Code |
Having same issue with VS code |
It looks like this is actually a See if you can reproduce this:
If so, the problem should be fixed soon: lint-staged/lint-staged#1032 In the meantime, pinning |
Husky can prevent you from bad git commit, git push and more. If you are getting this error check your code syntax, in case if you are getting this error even your code is valid. Please use the below command.
from: here |
same with vscode for me
// commitlint.config.js
module.exports = {
extends: ["@commitlint/config-conventional"]
}; |
randomly closed, it was the encoding was utf-16 maybe dont close without a comment |
try to restart your vscode |
or |
|
For me, this issue is not because of husky, but because of |
Hi people, a have a similar issue to run commands in pre-push hook. Via command-line it works without problems. My VS Code version is:
Output error: Inside file I have a npm command: |
In my case "lint-staged" configuration was missing from |
This worked for me |
In my case when trying to commit from my IDE it would give the non-descriptive error It turned out my IDE used an earlier node version (6.14.4 vs 7.19.1 from my terminal), upping the version fixed this for me. |
it seems from this thread that husky can have a lot of issues that cause the same vague error, this might need to be addressed |
Me too, greate~ |
This just disables husky for me. |
This does NOT resolve the issue, but a work around to ignore the issue. |
I was able to resolve this error by running each precommit command individually. Turns out my test command ( Note that Jest seems to hide that this actually causes an error code 🤦 and instead makes it look like a warning, so if this is your problem you'll never actually see an error code directly from Jest. That's probably why this only appeared as an error through Husky for me, and I imagine there could be many other situations where an individual command is swallowing the error code to make it look like Husky's fault. |
This was my issue. Thank you for your comment. |
I just renamed from |
Got the same error. |
I got the same error as well. |
You must to verify this because with this command you're disabling commit checks |
I checked mine and saw that my
was not directly in the root of the package.json |
Thanks, you saved my time. |
This worked for me: First I ran
And voila! Subsequent commits were successful |
The |
Just create a file called .lintstagedrc and put this:
|
Your "lint-staged": {
"**/*": ["prettier --write --ignore-unknown"],
"**/*.{ts,tsx}": ["jest --bail"]
}, to "lint-staged": {
"**/*": "prettier --write --ignore-unknown",
"**/*.{ts,tsx}": "jest --bail"
}, And the issue was fixed. |
That error happened me, too.
|
{ |
these 4 lines of code are saving me |
I have the same error without any output: #!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
FILES=`git diff --name-only --cached --diff-filter=d | grep -E '(ts|tsx)$'`;
if [ ! -z "$FILES" ]; then
for file in $FILES; do
npx prettier --write $file;
npx eslint --fix $file;
done
git add $FILES
else
true
fi Is there any way to force Husky to show what is the error? My script works fine If I comment out I've also tried this: FILES=`git diff --name-only --cached --diff-filter=d | grep -E '(ts|tsx)$'`;
for file in $FILES; do
npx prettier --write $file;
npx eslint --fix $file;
done
test ! -z "$FILES" && git add $FILES || true and Husky keep showing an error. |
So the problem was if the FILES is empty grep will return non-zero code and the whole hook will fail and the rest will not be executed. I've solved the issue with this code: FILES=`git diff --name-only --cached --diff-filter=d | grep -E '(ts|tsx)$' || true`;
if [ ! -z "$FILES" ]; then
for file in $FILES; do
npx prettier --write $file;
npx eslint --fix $file;
done
git add $FILES
fi |
I was having this problem and the output was complaining about "Unexpected token '??='". I'm using nvm, and this seems to be related to which version of node is loaded by default in the terminal (in this case, one which didn't understand this operator), regardless of my config switching node version based on the presence of a In my case when I checked I had version 14 pinned in my path. I was able to work around this by:
|
In my case husky was always getting node 14. Changing nvm default version didn't work or changing the PATH variable because the version was pinned in my .huskyrc file. I recommend you all checking that evil file. |
@mjaynixxz this is something different because you have an error from npm, not only the error code. Did you look into the log file? |
if deleting node modules and running lint in your project can't help try to restart your computer |
WORKED 😀 |
I updated my VSCode version.This fixed my issue. |
It Worked for me 👍 |
In my case, everything works if I commit from VSCode's integrated terminal, but it's not the case in SourceTree. |
Thanks for this Just adding that I had nvm installed inside git bash (for Windows), and I wasn't able to find the path to the nvm installed nodejs instances. |
I had this problem today with Tried many things from this thread and another, but nothing worked so I decided to go with P.S. if anyone would like to know: |
This works but you are now missing your hooks 😆 |
|
For those who tried |
* Husky pre-commit fails with code 1 - (#1014): typicode/husky#1014
In my case, I had below line in my pre-commit file..
This returned an empty
This runs expectedly in each case... |
Committing from vs-code Source control returns this error but the command line works fine
vscode version -
1.58.2
Command output
pre-commit
package json
The text was updated successfully, but these errors were encountered: