`husky install` fails when using `--prod` #914

ext · 2021-03-28T15:29:06Z

I have a package.json similar to:

{
  "scripts": {
    "prepare": "husky install"
  },
  "devDependencies": {
    "husky": "^5.2.0"
  }
}

Running npm install --prod (or NODE_ENV=production) will only install production dependencies and thus node_modules/.bin/husky will not be present. In my case this happens when trying to build a docker container where I want to install only the production dependencies.

$ npm install --prod

> foobar@1.0.0 prepare
> husky install

sh: line 1: husky: command not found
npm ERR! code 127
npm ERR! path /home/ext/foobar
npm ERR! command failed
npm ERR! command sh -c husky install

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ext/.npm/_logs/2021-03-28T15_18_18_181Z-debug.log

What is the suggested way to handle this scenario?

With husky 4 it worked properly as husky install wasn't needed.

The text was updated successfully, but these errors were encountered:

pinalbhatt · 2021-03-30T00:48:58Z

adding --ignore-scripts worked for me
RUN npm ci --only=production --ignore-scripts

ext · 2021-03-30T08:50:01Z

Thank you for the tips, maybe it could be added to the docs in case others face the same issue?

typicode · 2021-03-30T09:17:08Z

Yes, good suggestion. PR welcome.

rdmurphy · 2021-04-09T20:23:24Z

I had a similar issue and the problem with using a blanket --ignore-scripts is it affects all packages being installed. So for example, I had a project that needed scripts to run for installing a binary (like imagemin-jpegtran) because a package using it appeared in dependencies.

I don't know what the solution is, but it'll be difficult to consider husky as an option if using --production will only work if no other dependencies do need scripts to run on install, which is often out of my hands.

robhowell · 2021-04-26T11:02:16Z

I just hit this problem found this issue, and discovered that there is an official recommended approach, using the is-ci module: https://typicode.github.io/husky/#/?id=disable-husky-in-cidocker

ext · 2021-04-26T11:37:49Z

I just hit this problem found this issue, and discovered that there is an official recommended approach, using the is-ci module: https://typicode.github.io/husky/#/?id=disable-husky-in-cidocker

Most of the linked approaches wont help, --ignore-scripts is the best (only?) option so far.

Setting HUSKY=0 wont help as prepare/postinstall will still try to execute husky install (causing command not found).
Using [ -n "$CI" ] (or similar) in the scripts assume husky is a production dependency, if it is a devDependency it still causes command isn't found.
Using is-ci would only work if is-ci is a production dependency or it will also fail because is-ci isn't found instead.

Additionally building docker images locally will not trigger CI or is-ci as it is not running in a CI environment.

I guess another hack that might work would be:

# install all dependencies, get past prepare/postinstall
npm install --production=false

# remove all non-production dependencies
npm prune --production

But that would be really wasteful and inefficient.

pinalbhatt · 2021-04-26T11:43:25Z

For now i am using this solution RUN npm set-script prepare "" && npm ci --only=production in my Docker file

vith · 2021-05-05T13:28:17Z

Using is-ci would only work if is-ci is a production dependency or it will also fail because is-ci isn't found instead.

is-ci contributes 84 KiB to node_modules, so this is not too bad.

"scripts": {
    "prepare": "is-ci || husky install"
}

works for me with one caveat: is-ci doesn't seem to detect npm ci --production as being "CI"...

At least CI=1 npm ci --production can complete successfully now.

ext · 2021-05-05T18:04:25Z

[..] so this is not too bad

I have to disagree with you there.

It erodes the purpose of production dependencies. If the production dependencies is a mix of runtime and buildtime dependencies why even keep them separate?
- This becomes worse if you use any kind of license or security scanner as it produces more noise when scanning dependencies which won't really affect the runtime.
It sets a bad precedent for other packages, if this would be the solution it could quickly lead to many other packages needing the same treatment.
84 KiB is still 84 KiB too much in my opinion, similarly there is one transitive dependency ci-info being pulled as well.
If it would be in a library all the consumers of the package would get this dependency as well (and possibly conflicting versions).

I still value your suggestion thought. Maybe it will help someone else?

ismay · 2021-05-22T16:06:17Z

I think this is related: #981. Core topic seems that the lifecycle hooks are sometimes triggering in circumstances where we don't want them to run (ci, installation as a dependency (production install)). I can see the appeal of having husky be agnostic to what enviroment it's being installed in, but the recommendations currently in the docs don't seem to cover all potential scenarios.

stale · 2021-07-21T16:32:09Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

rchl · 2021-07-21T16:52:38Z

Valid issue IMO and the workarounds above are just workarounds.

stale · 2021-09-19T17:20:58Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

ext · 2021-09-19T18:53:22Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I still consider this to be an issue.

rchl · 2021-11-14T20:25:41Z

The way the package works after v4 is problematic as evident by this and other related issues reported in this repo. I wonder why author doesn't want to acknowledge that the new way of handling hooks is just too problematic (even if intentions were good) and probably should be reverted.

cujarrett · 2021-12-01T20:04:02Z

I'm running into this out of the blue on ~~one~~ two of my apps w/ husky 7.0.4.

I've deleted node_modules, package-lock.json and ran npm install to rebuild them w/ no success.

I've edited my deploy job to npm ci --only=production --ignore-scripts w/ no success.

Big sad.

cujarrett · 2021-12-01T20:15:59Z

I solved my occurance of this with @pinalbhatt 's suggestion of npm set-script prepare "" && npm ci --only=production.

justinhaaheim · 2021-12-22T02:39:38Z

The "custom script" option listed in the husky docs worked best for me while deploying a small hobby project to Heroku, which is not supported by the is-ci tool. The fact that it's a node script adds the flexibility to check for production environment:

// prepare.js

const isProduction = process.env.NODE_ENV === 'production';
const isCi = process.env.CI !== undefined;

if (!isCi && !isProduction) {
  require('husky').install();
}

stale · 2022-02-20T04:04:34Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If `husky` is not present, `npm` fails to install `fetch-retry` as a dependency for `production` or `ci` environments. ``` npm ERR! code 127 npm ERR! git dep preparation failed npm ERR! command /home/ubuntu/.nvm/versions/node/v12.22.10/bin/node /home/ubuntu/.nvm/versions/node/v12.22.10/lib/node_modules/npm/bin/npm-cli.js install --force --cache=/home/ubuntu/.npm --prefer-offline=false --prefer-online=false --offline=false --no-progress --no-save --no-audit npm ERR! > fetch-retry@5.0.1 prepare npm ERR! > husky install npm ERR! npm WARN using --force Recommended protections disabled. npm ERR! sh: 1: husky: not found npm ERR! npm ERR! code 127 npm ERR! npm ERR! path /home/ubuntu/.npm/_cacache/tmp/git-clone-9f0cb372 npm ERR! npm ERR! command failed npm ERR! npm ERR! command sh -c husky install npm ERR! npm ERR! npm ERR! A complete log of this run can be found in: npm ERR! npm ERR! /home/ubuntu/.npm/_logs/2022-02-21T00_27_56_429Z-debug.log npm ERR! A complete log of this run can be found in: npm ERR! /home/ubuntu/.npm/_logs/2022-02-21T00_27_56_749Z-debug.log ``` They offer a few alternative to the "default install" here: https://typicode.github.io/husky/#/?id=disable-husky-in-cidockerprod. See also typicode/husky#914.

elyobo · 2022-03-03T23:30:25Z

We're seeing this with Google App Engine (node flex environment), where it's Google doing the npm install that's somehow kicking this off. Can't reproduce it locally 🤷

stale · 2022-05-03T01:33:01Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

malko · 2022-05-19T14:13:41Z

My 2 cents to this issue that make our CI pipelines fail too.
Using the prepare npm script is IMHO not a good idea at all. the prepare script is called not only on install but also on publish and perhaps i'm missing something but I don't want it to be executed on publish at all.
Also it will make stuffs more complicated if you intend to use that prepare script for yourself as you will have to deal with including "husky install" somewhere in your prepare script.

Finally I think best options so far are:

npm set-scripts prepare "" before running install or publish during you CI jobs.
replace your prepare script with:
"prepare": "if [[ -x \"$(command -v husky)\" ]]; then husky install; fi"

I can't recommend the --ignore-scripts as it will avoid all other legitimate script to be run, it can't be a good solution.

joaosouzaminu · 2022-07-14T22:14:25Z

My 2 cents to this issue that make our CI pipelines fail too. Using the prepare npm script is IMHO not a good idea at all. the prepare script is called not only on install but also on publish and perhaps i'm missing something but I don't want it to be executed on publish at all. Also it will make stuffs more complicated if you intend to use that prepare script for yourself as you will have to deal with including "husky install" somewhere in your prepare script.

Finally I think best options so far are:

npm set-scripts prepare "" before running install or publish during you CI jobs.

replace your prepare script with:
"prepare": "if [[ -x \"$(command -v husky)\" ]]; then husky install; fi"

I can't recommend the --ignore-scripts as it will avoid all other legitimate script to be run, it can't be a good solution.

Just a nit pick, the npm command actually is set-script in singular.

ThePlenkov · 2022-07-18T09:55:17Z

I have solved the same problem by usage of an own tiny CLI:
"prepare": "check NODE_ENV=production || husky install"
where check is installed by:
npm install check-env-cli

The only point - this module has to be then production dependency then . Meanwhile why I see is a good way

it's crosss env, while using is OS-dependent
it works with predefined pipelines ( sometimes command like npm ci --production is defined outside of the project in an external builder ) So you cannot inject there parameters like --omit..
this checker allows to use any environment variable - so you can make condition even more specific. --production flag triggers NODE_ENV=production - that's why I use it and is enough.

Alternative usage. If you wish not to have this module as a global dependency - you can also use npx:

    "prepare": "npm run is-prod || husky install",
    "is-prod": "npx -y check-env-cli NODE_ENV=production"

stale · 2022-09-16T12:39:02Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

ext · 2022-09-18T23:19:19Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I still consider this to be an issue.

glensc · 2022-09-26T03:24:01Z

I have tried alternative approaches instead of using prepare script:

add is-ci to dev dependencies
"postinstall": "is-ci || husky install || echo Skipped husky setup"

this will just show error when binary is not available. but using this script is a problem while prepare is ran at local dependencies install then "postinstall" is also executed when package is used as dependency. echo was chosen for windows compatibility, as constructs like || : or || true don't work there.

also, while the most problematic place is CI invocation, the check should be really is-dev to account for scenarios where you run yarn install --production locally

stec00 · 2022-09-29T15:10:35Z

Updated version of the popular workaround for this given above from @pinalbhatt - since later npm versions give warnings that set-script and --prod are both deprecated:

npm pkg delete scripts.prepare && npm install --omit=dev

(~~Note the single space rather than empty string~~ - have raised a SO question in case some further light can be thrown on this: https://stackoverflow.com/questions/73896448. UPDATE - got a good answer to this and have now updated this one accordingly.)

glensc · 2022-09-29T16:24:02Z

I wanted to say just use npm pkg delete scripts.prepare, but you already got it :)

ianchanning · 2022-12-16T18:48:01Z

The "custom script" option listed in the husky docs worked best for me while deploying a small hobby project to Heroku, which is not supported by the is-ci tool. The fact that it's a node script adds the flexibility to check for production environment:
// prepare.js

const isProduction = process.env.NODE_ENV === 'production';
const isCi = process.env.CI !== undefined;

if (!isCi && !isProduction) {
  require('husky').install();
}

Yes - I like this the best as then I can document in that script why I have to do all these workarounds. With all other solutions they will just be undocumented workarounds buried in CI tools or package.json.

GabrielDelepine · 2023-01-10T09:41:29Z

There are a large variety of approaches, and not one is satisfying

I personally prefer

{
  "prepare": "test -d node_modules/husky && husky install || echo \"husky is not installed\"",
}

IMO, it's evidence that many projects are getting deployed with dev dependencies, which is sad to realize

NachtRitter · 2023-03-30T10:46:17Z

If you use command like npm ci --omit=dev you can access those property via $npm_config_omit.
According to value of $npm_config_omit you can decide to run husky install command or not.

{
  "postinstall": "if [ \"$npm_config_omit\" = \"dev\" ]; then echo \"Skip husky installation\"; else husky install; fi"
}

reference: typicode/husky#914 (comment) typicode/husky#920 (comment) fix: bc16284#commitcomment-117186018 fix: #12686

reference: typicode/husky#914 (comment) typicode/husky#920 (comment) fix: DIYgod@bc16284#commitcomment-117186018 fix: DIYgod#12686

mickael-h · 2023-07-19T23:14:08Z

If you use command like npm ci --omit=dev you can access those property via $npm_config_omit. According to value of $npm_config_omit you can decide to run husky install command or not.
{
  "postinstall": "if [ \"$npm_config_omit\" = \"dev\" ]; then echo \"Skip husky installation\"; else husky install; fi"
}

Best solution by far. Doesn't require extra packages, or modifying the run script.

kostia1st · 2023-10-01T17:37:43Z

"prepare": "if [[ -x \"$(command -v husky)\" ]]; then husky install; fi"

@malko Thanks for the tip, this actually did the job for me. 🙏

UPD: Had to adjust it a bit to make it also work in my local env:

"prepare": "sh -c 'if [[ -x \"$(command -v husky)\" ]]; then  husky install; fi'",

kael-shipman · 2023-10-13T20:41:14Z

My take:

{
  "prepare": "command -v husky &>/dev/null && husky install || true"
}

Don't know how cross-env it is, but works just fine for me on linux.

lucasmelosilva · 2024-01-07T16:52:28Z

adding --ignore-scripts worked for me RUN npm ci --only=production --ignore-scripts

In version 8.x and above use --omit=dev flag to install only regular dependencies:
RUN npm ci --omit=dev --ignore-scripts
This will install only dependencies, and not devDependencies, regardless of the value of the NODE_ENV environment variable.
If you use 6.x or an earlier version, you need to use the --only=prod flag instead.

greenhat616 mentioned this issue Apr 22, 2021

v6's postinstall breaks Yarn 2's "workspaces focus" command #939

Closed

rdmeal mentioned this issue Apr 22, 2021

sh: husky: command not found #945

Closed

ismay mentioned this issue May 22, 2021

Prepare script triggers when installing this lib as a dependency RJWadley/stylelint-no-unsupported-browser-features#151

Closed

stale bot added the wontfix label Jul 21, 2021

stale bot removed the wontfix label Jul 21, 2021

dotnetCarpenter mentioned this issue Sep 16, 2021

Husky does not exit early when HUSKY=0 #1046

Closed

stale bot added the wontfix label Sep 19, 2021

stale bot removed the wontfix label Sep 19, 2021

mmounts mentioned this issue Nov 1, 2021

Why do we need to create the "prepare": "husky install" script for package.json? #1016

Closed

rchl mentioned this issue Nov 14, 2021

chore(deps-dev): bump husky from 4.3.8 to 7.0.4 typescript-language-server/typescript-language-server#298

Closed

stale bot added the wontfix label Feb 20, 2022

bamse16 mentioned this issue Feb 21, 2022

Replaced npm prepare step to fix fail to install jonbern/fetch-retry#69

Merged

stale bot added the wontfix label May 3, 2022

typicode removed the wontfix label May 3, 2022

stale bot added the wontfix label Sep 16, 2022

stale bot closed this as completed Sep 26, 2022

zanami added a commit to zanami/slr-storefront that referenced this issue Apr 12, 2023

husky not found in prepare workaround typicode/husky#914

2e1af0b

TonyRL added a commit to DIYgod/RSSHub that referenced this issue Jun 21, 2023

chore: fix install from git with production flag

9b31d57

reference: typicode/husky#914 (comment) typicode/husky#920 (comment) fix: bc16284#commitcomment-117186018 fix: #12686

bywhite0 pushed a commit to bywhite0/RSSHub that referenced this issue Jun 22, 2023

chore: fix install from git with production flag

e0fca80

reference: typicode/husky#914 (comment) typicode/husky#920 (comment) fix: DIYgod@bc16284#commitcomment-117186018 fix: DIYgod#12686

nullqwertyuiop pushed a commit to nullqwertyuiop/RSSHub that referenced this issue Jun 27, 2023

chore: fix install from git with production flag

f5faf6f

reference: typicode/husky#914 (comment) typicode/husky#920 (comment) fix: DIYgod@bc16284#commitcomment-117186018 fix: DIYgod#12686

gwdawson mentioned this issue Jul 17, 2023

Fix npm publish workflow grafana/lezer-logql#34

Merged

msterle mentioned this issue Jan 8, 2024

Add integration/e2e tests scaffold digicatapult/veritable-cloudagent#37

Merged

husky install fails when using --prod #914

husky install fails when using --prod #914

Comments

ext commented Mar 28, 2021

pinalbhatt commented Mar 30, 2021

ext commented Mar 30, 2021

typicode commented Mar 30, 2021 • edited

rdmurphy commented Apr 9, 2021

robhowell commented Apr 26, 2021

ext commented Apr 26, 2021

pinalbhatt commented Apr 26, 2021

vith commented May 5, 2021

ext commented May 5, 2021

ismay commented May 22, 2021

stale bot commented Jul 21, 2021

rchl commented Jul 21, 2021

stale bot commented Sep 19, 2021

ext commented Sep 19, 2021

rchl commented Nov 14, 2021 • edited

cujarrett commented Dec 1, 2021 • edited

cujarrett commented Dec 1, 2021

justinhaaheim commented Dec 22, 2021

stale bot commented Feb 20, 2022

elyobo commented Mar 3, 2022

stale bot commented May 3, 2022

malko commented May 19, 2022

joaosouzaminu commented Jul 14, 2022

ThePlenkov commented Jul 18, 2022 • edited

stale bot commented Sep 16, 2022

ext commented Sep 18, 2022

glensc commented Sep 26, 2022

stec00 commented Sep 29, 2022 • edited

glensc commented Sep 29, 2022

ianchanning commented Dec 16, 2022

GabrielDelepine commented Jan 10, 2023 • edited

NachtRitter commented Mar 30, 2023

mickael-h commented Jul 19, 2023

kostia1st commented Oct 1, 2023 • edited

kael-shipman commented Oct 13, 2023

lucasmelosilva commented Jan 7, 2024

`husky install` fails when using `--prod` #914

`husky install` fails when using `--prod` #914

typicode commented Mar 30, 2021 •

edited

rchl commented Nov 14, 2021 •

edited

cujarrett commented Dec 1, 2021 •

edited

ThePlenkov commented Jul 18, 2022 •

edited

stec00 commented Sep 29, 2022 •

edited

GabrielDelepine commented Jan 10, 2023 •

edited

kostia1st commented Oct 1, 2023 •

edited