We need a way to specify which shell a script is written for

[jameshfisher]

There appears to be no way to specify which shell is to be used to execute an install script defined in a package.json.

• I am aware of npm config set script-shell, but is not appropriate, because we can't rely on the end user (installer) having the correct npm config.
• I am also aware of .npmrc, but packaging one alongside the package.json does not appear to be respected by npm (steps to reproduce below).

IMO, we need the equivalent of the shebang #! for these inline scripts, e.g. the ability to set { ... "script-shell": "bash" } in the same package.json where the scripts are defined.

Current Behavior:

Prints the literal string $SHELL.

Expected Behavior:

Prints something like /usr/bin/bash.exe.

Steps To Reproduce:

1. Create a package.json { "name: "foo", "scripts": { "install": "echo $SHELL" } }.
2. Alongside it, create an .npmrc with script-shell = bash.
3. Install the package with e.g. npm install foo from e.g. PowerShell or e.g. Git Bash on Windows.

Environment:

• OS: Windows 10
• Node: 12.16.3
• npm: 6.14.8

[jameshfisher]

I'm also aware I could write things like

"scripts": {
   "install": "bash -c 'echo $SHELL'"
}

But this is still making the assumption that all possible arbitrary shells that the installer could be using will interpret the string "bash -c 'echo $SHELL'" in the same way.

[MylesBorins]

Pinging the @npm/cli team

[isaacs]

This is the reason why so many install/build scripts are written as Node.js programs, since you're it's much more likely that node install.js will work.

I'm open to putting the script-shell config in a package.json file somewhere. Maybe it should be in "engines" somewhere, since it's kind of like "this is the platform that should be used to run this package"?

{
  "engines": {
    "node": ">=10",
    "npm": ">=6",
    "shell": "bash"
  }
}

Also, it seems like you expect npm (or perhaps @npmcli/run-script) to add the script-shell config to the SHELL environment variable, which is seems completely reasonable to me.

Maybe the script-shell config should also default to whatever process.env.SHELL is set to? (Currently it's sh on unix, cmd on windows, and ignores the SHELL environ.) This is probably the most hazardous suggestion, but I could see it avoiding some surprising situations.

So, looks like, three distinct but related issues. (Set script-shell in package.json, set env.SHELL to script-shell, and default script-shell to env.SHELL if set.) Anything I missed there?

[jameshfisher]

Thanks @isaacs. For context, the specific problem I had was that I developed a package with an install script that assumed bash (or similar). Then I started using it in a Windows/PowerShell context, and it didn't work.

Setting script-shell in the package.json is the most important thing for me, as it solves my specific problem. I don't mind much where it's set in the package.json.

I did expect npm to set the SHELL var, although this is less important, as I was only using this to test npm's behavior - it's not essential to solving my PowerShell compat problem.

Defaulting to the current SHELL also sounds reasonable. Though I actually don't know what the current behavior is exactly - only that the chosen shell differs by OS. I also wonder whether changing that behavior would break backwards compatibility?

[isaacs]

Yeah, defaulting the script-shell config to process.env.SHELL is definitely something that would need to go through an rfc process. Currently we always default to sh on Unix and cmd.exe on Windows. If a script works on sh, it'll most likely also work in bash or zsh, but of course if someone is running fish, then all bets are off.

Setting script-shell in the package.json is the most important thing for me, as it solves my specific problem. I don't mind much where it's set in the package.json.

I think the biggest hazard would be setting "shell": "cmd.exe" in package.json, which can never work on non-windows platforms.

Another option is that we could sniff for the presence of bash or sh on Windows systems, and use that if available.

[jameshfisher]

I would guess that approximately 0 people would set "shell": "cmd.exe", even those developing on Windows - it would nearly always be used as a way to switch away from the cmd.exe default. I have no data for this though.

I prefer the ability to explicitly state the shell with "script-shell": "bash", compared to sniffing for presence of shells - mainly because this precedent for explicit config is set by .npmrc and #! shebang.

[jpvosloo]

I would also like the option to set the preferred shell in package.json.
In some cases I would like to display a message and halt the script if the preferred shell is not available, for this I would need the $SHELL to return which shell is currently executing.

[sarimarton]

Is there any progress on this? It's really a struggle not being able to define the shell in the project. It doesn't make sense that the behavior of npm scripts are non-deterministic.

[josStorer]

I prefer to config shell for different platforms, like

{
  "engines": {
    "node": ">=10",
    "npm": ">=6",
    "windows-shell": "pwsh",
    "unix-shell": "tcsh",
    "darwin-shell": "zsh",
  }
}

[olfek]

I second this

[trusktr]

This is a nice idea. I'd really just need to configure the shell for Windows mostly. macOS/Linux have typically no issues.

[trusktr]

What about a syntax idea, f.e.:

"scripts": {
  "foo<<pwsh": "Get-Command cmd",
  "bar<<bash": "which npm",
}

where npm run foo would use PowerShell, and npm run bar would use bash. Etc.

[trusktr]

Oh, another idea is, maybe the syntax could be slightly more familiar:

"scripts": {
  "foo#!pwsh": "Get-Command cmd",
  "bar#!bash": "which npm",
}

[jmcscript]

I use PowerShell. But, because Windows users likely install Git along with Git Bash, I'd recommend setting that as the default on Windows systems if the path is available.

Additionally, that will unify most command-line tools available to users, such as date, grep, ssh, etc.