Hardhat-core `internal/cli/cli.js` is not executable anymore

[ottodevs]

Recent versions of hardhat changed the way cli.js is built, so it has not executable permission anymore, that causes new installations to fail while trying to call any hardhat command with Permission denied. It is specially disturbing in CI environments.

To reproduce, just install an older version of hardhat in an empty node project (ensure you are not caching dependencies) and run ls -ll ./node_modules/hardhat/internal/cli/cli.js

The output permissions show: lrwxr-xr-x (note the x that allows the program to be executable)

Now try with the latest version and the output for ls -ll ./node_modules/hardhat/internal/cli/cli.js is now: -rw-r--r-- so the command hardhat that is just an alias for cli.js is not working anymore until making it executable

[github-actions[bot]]

This issue is also being tracked on Linear.

We use Linear to manage our development process, but we keep the conversations on Github.

LINEAR-ID: b7ba7e4f-0a56-4e10-93ad-32a12b5bfab0

[ottodevs]

It does seem related to our code environment, because I tried several versions and all fail with the same issue, also with github actions:

Maybe it is related to pnpm or because I am using hardhat as a regular dependency instead of devDependency, I will keep trying and updating

[ottodevs]

As I was suspecting the issue is related to pnpm when node-linker = hoisted is defined in .npmrc so not specifically related to hardhat, but it happens with some packages like hardhat while others are installed with the proper permissions.

The current solution is to add prefer-symlinked-executables = false to .npmrc

Reference: https://github.com/pnpm/pnpm/issues/5252

[fvictorio]

Hi @ottodevs, do you think there's something we can do on our side?

[ottodevs]

Hi @ottodevs, do you think there's something we can do on our side?

Maybe there is a potential solution to generate the correct executable permissions for symlinked executables, as there are so many libraries that work correctly that way, but at this moment I am not sure what would be the potential fix... right now the workaround is adding that .npmrc flag, but that is probably degrading pnpm experience, since preventing symlinked executables will use more disk space.

I don't know the correct answer, so maybe for now it is ok to close this, unless you have any idea on what is happening or enough amount of devs demand this to consider adding some priority.

[fvictorio]

Thank you. I'm going to close it mainly for bookkeeping reasons but we do monitor closed issues. If you or anyone else has any idea of how to approach this, please leave a comment here.