Hardhat cannot be initialized in git bash

[fvictorio]

Reproduction steps:

1. Use windows (sorry)
2. Open git bash
3. Install hardhat in an empty directory npm i --save-dev hardhat
4. npx hardhat

The project initialization project should show up, but instead the "not inside a Hardhat project" message is shown.

[Leon-Africa]

Here is an interim solution: #1400 (comment)

[fvictorio]

Possible cause: #1460 (comment)

[Elyx0]

Confirmed on windows. Yarn or npm, ./node_modules/.bin/hardhat or with npx

[aftermathdigital]

FWIW, I don't get this bug in powershell. If other people are, I think it's actually unrelated and a seperate bug.

I thought I'd dig in to why hardhat isn't working in git bash, and I think it's a fairly complicated issue... I believe it's related to this:

nodejs/node#3006

Hardhat appears to check if it's running in an interactive shell in the following segment:

https://github.com/nomiclabs/hardhat/blob/4ede55036d8dee72f28542d3db9c8b93f7debe93/packages/hardhat-core/src/internal/cli/cli.ts#L88-L95

Which will be tricked into thinking that it's not, due to process.stdout.isTTY === true evaluating false.

As a result, await project_creation_1.createProject(); never gets called, hence the error that you're not inside a hardhat project.

I thought one option might be changing the if statement in the cli.js main function to the following:

        if (hardhatArguments.config === undefined &&
            !project_structure_1.isCwdInsideProject() &&
            (process.stdout.isTTY === true || process.env.MSYSTEM)) {

But that that only partially works, as mingw not being an actual TTY appears to prevent the dialogue options hardhat presents from being updated based on user-input; they do technically work, it's just the user gets no visual feedback that their input is doing anything. Plus it would also mask non-interactive invocations on such a system, which might actually currently work.

An interim fix might be to check if the user has process.env.MSYSTEM and tell them their terminal is not supported.

[alcuadrado]

Nice findings @aftermathdigital! Do you know where can we read more about msystem? I'm not finding its docs in google. Is it a mingw specific thing?

[aftermathdigital]

I'll be honest, I just checked my environment in a fresh instance of git-bash and picked something which looked like it was specific to that terminal.

A quick google indicates here:

https://stackoverflow.com/questions/37460073/msys-vs-mingw-internal-environment-variables

That it looks like I've gotten lucky and found one that is specific to these weird pseudo terminals.

It's probable there are better ways of knowing for sure.

[frostbytedata]

I seem to still be seeing this with Git Bash on Windows 10. FWIW I am using yarn with workspaces in a monorepo. This is my package.json for the hardhat workspace in my project:

  "name": "hardhat",
  "version": "0.0.1",
  "description": "contracts",
  "main": "index.js",
  "author": "developer",
  "license": "MIT",
  "private": true,
  "scripts": {
    "accounts": "npx hardhat accounts",
    "compile": "npx hardhat compile",
    "clean": "npx hardhat clean",
    "test": "npx hardhat test",
    "chain": "npx hardhat node --show-stack-traces",
    "help": "npx hardhat help",
    "gas": "REPORT_GAS=true npx hardhat test",
    "deploy": "npx hardhat run scripts/deploy.ts",
    "ts-node-deploy": "TS_NODE_FILES=true npx ts-node scripts/deploy.ts",
    "eslint": "npx eslint '**/*.{js,ts}'",
    "eslint-ix": "npx eslint '**/*.{js,ts}' --fix",
    "prettier": "npx prettier '**/*.{json,sol,md}' --check",
    "prettier-fix": "npx prettier '**/*.{json,sol,md}' --write",
    "solhint": "npx solhint 'contracts/**/*.sol'",
    "solhint-fix": "npx solhint 'contracts/**/*.sol' --fix"
  },
  "devDependencies": {
    "@nomiclabs/hardhat-ethers": "^2.0.2",
    "@nomiclabs/hardhat-etherscan": "^2.1.6",
    "@nomiclabs/hardhat-waffle": "^2.0.1",
    "@typechain/ethers-v5": "^7.2.0",
    "@typechain/hardhat": "^2.3.1",
    "@types/chai": "^4.2.22",
    "@types/mocha": "^9.0.0",
    "@types/node": "^16.10.9",
    "chai": "^4.3.4",
    "dotenv": "^10.0.0",
    "ethereum-waffle": "^3.4.0",
    "ethers": "^5.4.7",
    "hardhat": "^2.6.6",
    "hardhat-abi-exporter": "^2.3.0",
    "hardhat-gas-reporter": "^1.0.4",
    "ts-node": "^10.3.0",
    "typechain": "^5.2.0",
    "typescript": "^4.4.4"
  }
}

Let me know if there is any other info I can provide to help get this odd bug knocked out.

[benjaminmbrown]

Same issue here on Win 10. Tried to install with yarn & nvm via cmd, bash, and powershell. Don't have it installed globally. Been dealing with this for a few days.

[alcuadrado]

@benjaminmbrown, @aftermathdigital mentioned somewhere that there's a way to install git bash that makes this work. He event showed me a screenshot of how to do it. It was an option in the normal installation.

Also, WSL should work.

[aftermathdigital]

WSL is the correct answer, however if you're looking for something quick, here is what I found before:

#1719 (comment)

You only need to use the workaround when initialising the repo, because AFAIK that's the only command with an interactive terminal. Everything else should work as usual.

[alcuadrado]

I wonder if we can detect when the users are running windows, not WSL, and the project setup fails to run, and show a better error message instructing them to use WSL. WDTY? //cc @fvictorio

[fvictorio]

That seems doable: microsoft/WSL#423 (comment)

[fvictorio]

I realize now that my previous comment makes no sense, @alcuadrado was talking about detecting windows, not WSL 😅

Checking process.platform === "win32" when HH1 is thrown should be enough. This expression is true in cmd, powershell and git bash, but not on WSL.

We should throw a different error in this case. The message should take the user to a section of our docs that explains how to setup a project on Windows. The tl;dr of that section would be:

• Just use WSL and everything should work fine.
• If you don't want to use WSL, then initialize the project in cmd/powershell and then continue using git bash after the project is initialized.

[aftermathdigital]

I'll have to try it, but if I'm reading this correctly when hh1 is thrown, if the platform is windows then you're using that as a conditional check that the user is in gitbash.

I think there's an edge case where this won't hold true - for instance where hardhat is invoked outside of an initialised project directory, but not in the context of a tty (such as in the context a batch/python script, or similar).

This is probably acceptable, but it might lead to a confusing message in that case, since the user will be linked to documentation that tells them to use a terminal the may already be using, when their actual mistake is not running in an initialised directory.

If you have a pull for me to test I can do that, and I can check the above condition :)

[alcuadrado]

I think there's an edge case where this won't hold true - for instance where hardhat is invoked outside of an initialised project directory, but not in the context of a tty (such as in the context a batch/python script, or similar).

This check would only happen in the cli, so the edge case wouldn't be present.
Update: you are right

[ArthurBonsu]

Good day I am still experiencing the issue over Ubuntu backed WSL on Windows OS as well as Gitbash. Please I will need some assistance. All my compilations working:Hardhat wasn't initialized

Raised an issue to here : https://stackoverflow.com/questions/71131584/hardhaterror-hardhat-wasnt-initialized
Is there a way around using the WSL option? Issue still persisting

[aftermathdigital]

woah, this looks like a different error to the one this issue was created to capture.

The issue in this bug is that in gitbash specifically (and possibly other pseudo terminals) hardhat can't tell it's being invoked interactively, which is a problem if you're expecting to interactively initialize a project.

This bug looks like something totally different.

If at all possible, could you point us at a repo to re-produce this?

If not, can you describe how your build process works? I don't think this is to do with the gitbash pseudo-terminal.

[ArthurBonsu]

Using Hardhat with, compiles successfulyy and deploys successfully Only issue with general build Over Gitbash Compiler ignoring minor warnings 1. //Building types 2. /// Making Production Build _[Ignore Page Warnings] 3. Finally completing build //Error, cannot see the initialized hardhat (although hardhat has been initialized and compilations made) //I will try to reproduce on WSL soon

…

On Wed, Feb 16, 2022 at 4:57 AM aftermathdigital ***@***.***> wrote: woah, this looks like a different error to the one this issue was created to capture. The issue in this bug is that in gitbash specifically (and possibly other pseudo terminals) hardhat can't tell it's being invoked interactively, which is a problem if you're expecting to interactively initialize a project. This bug looks like something totally different. If at all possible, could you point us at a repo to re-produce this? If not, can you describe how your build process works? I don't think this is to do with the gitbash pseudo-terminal. — Reply to this email directly, view it on GitHub <#1408 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIYNVNB3VVYS5EHRTHFPGTU3K42NANCNFSM42746QFQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[ArthurBonsu]

[ArthurBonsu]

Reproducing Errorr from WSL console
I will try to reproduce the error from a next.js initialized project from scratch and see how it goes

[ArthurBonsu]

Access Link For Reproduction https://1drv.ms/u/s!AhVZJfBHyOQldO9CbAi1582vxA8 On Wed, Feb 16, 2022 at 6:18 AM Bonsu Adjei-Arthur ***@***.***> wrote:

…

Using Hardhat with, compiles successfulyy and deploys successfully Only issue with general build Over Gitbash Compiler ignoring minor warnings 1. //Building types 2. /// Making Production Build _[Ignore Page Warnings] 3. Finally completing build //Error, cannot see the initialized hardhat (although hardhat has been initialized and compilations made) //I will try to reproduce on WSL soon On Wed, Feb 16, 2022 at 4:57 AM aftermathdigital ***@***.***> wrote: > woah, this looks like a different error to the one this issue was created > to capture. > > The issue in this bug is that in gitbash specifically (and possibly other > pseudo terminals) hardhat can't tell it's being invoked interactively, > which is a problem if you're expecting to interactively initialize a > project. > > This bug looks like something totally different. > > If at all possible, could you point us at a repo to re-produce this? > > If not, can you describe how your build process works? I don't think this > is to do with the gitbash pseudo-terminal. > > — > Reply to this email directly, view it on GitHub > <#1408 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEIYNVNB3VVYS5EHRTHFPGTU3K42NANCNFSM42746QFQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you commented.Message ID: > ***@***.***> >

[alcuadrado]

@ArthurBonsu create a new issue if you think you are having a problem. Please include a clear explanation of what's going on and the steps to reproduce it.

[alcuadrado]

Locking this conversation. Please if someone gets to this same error, open a new issue.