Improvements to pnpm setup

[zkochan]

This is the first result when searching "pnpm could not infer shell type", and despite being closed does not give any useful information on how to actually resolve the problem.

Pnpm's shell detection depends on one of the environment variables ZSH_VERSION, BASH_VERSION, FISH_VERSION, or SHELL being set. None of those shells actually exports their *_VERSION variables by default, so we can ignore all of that and it comes down to SHELL.

The problem in the original issue is that the python:3.9.12-bullseye image uses dash, not bash, zsh, or fish, as its /bin/sh. So running curl -fsSL https://get.pnpm.io/install.sh | sh - runs in dash, which is not a supported shell for pnpm's detection. If you do curl -fsSL https://get.pnpm.io/install.sh | bash - instead it'll work after a fashion (it'll install pnpm locally for the container's default user, not to /usr/local despite PNPM_HOME being set to that; the best way to actually install pnpm globally seems to still be npm install --global pnpm as root).

I came here instead because I was running pnpm setup inside an already-running container (with pnpm installed globally via npm, as above) and it was giving the "could not infer shell type" error even though I was running in bash. In this case the problem is that the non-login environment the container starts up with doesn't export SHELL. That can be worked around with export SHELL, or by doing like SHELL=$SHELL pnpm setup to pass the variable so pnpm setup can see it. Then either way source .bashrc works to pick up the changes pnpm setup made, no need to open a new terminal.

Originally posted by @anomiex in #4495 (comment)

[frantic1048]

I am an elvish(https://elv.sh) shell user. I encountered the UNSUPPORTED_SHELL error while running pnpm setup. After digging into updateShell() function, I noticed the function is setting some environment variables. As a result, I manually updated the essential environment variables in my shell config to make features like pnpm link --global work properly.

I'm not asking for adding support for yet another magical shell here. Different shells may have different ways to set environment variables. And different users may manage their environment variables in different ways. Supporting updating environment variable config for a specific shell is nice to have, but not a must.

How about leaving a message describing what environment variables should be updated when an unsupported shell is encountered? Thus users could know what goes on when pnpm setup cannot handle their shell config.

[zkochan]

Sounds good.

[gasacchi]

same with nushell, getting shell unsupported when running pnpm setup.
even after manually set environment variable still getting error

let-env PNPM_HOME = "~/.local/share/pnpm"
let-env PATH = ($env.PATH | append "~/.local/share/pnpm")

error when running pnpm -g list

ERROR  The configured global bin directory "~/.local/share/pnpm" is not in PATH
For help, run: pnpm help list

[tiamo]

workaround

let-env PNPM_HOME = $"($env.HOME)/Library/pnpm"
let-env PATH = ($env.PATH | append $env.PNPM_HOME)

[luccahuguet]

this is a helpful workaround and works with the new nushell syntax:

#6476 (comment)

For people who didn't manage to run the install script when using Nu, do the following:

Open a bash shell and temporarily set the value of the SHELL environment variable to bash (so do something like export SHELL=bash). Then you can run the install script:

curl -fsSL https://get.pnpm.io/install.sh | bash -

Most likely, pnpm will be installed to your $HOME/.local/share/pnpm. So add the following to your env.nu (near the end) in ~/.config/nushell:

$env.PNPM_HOME = $"($env.HOME)/.local/share/pnpm"
$env.PATH = ($env.PATH | split row (char esep) | prepend $env.PNPM_HOME )