Non-Interactive pnpm install --no-optional hangs without --config.confirmModulesPurge=false

[pmaoui]

Hello,

I recently encountered an issue with pnpm version 8.6.6 during a Docker build process.

When running the command in a Dockerfile:

pnpm install --no-optional -r --offline --ignore-scripts --frozen-lockfile 

the command did not fail but led to an empty node_modules folder.

I found that when running the same command interactively inside the Docker container, a confirmation prompt was shown. After confirming with Y, the command executed as expected.

However, this behavior is problematic in non-interactive environments like Docker builds, where the command cannot receive any user input.

As a workaround, I used the --config.confirmModulesPurge=false option to automatically confirm the prompt, as shown below:

pnpm install --no-optional -r --offline --ignore-scripts --frozen-lockfile --config.confirmModulesPurge=false

This successfully bypassed the confirmation and the node_modules folder was correctly populated.

Although I was able to find a workaround, I believe it would be helpful to improve the handling of this situation, perhaps by making the --no-optional flag non-interactive by default, or providing clear documentation about the need for --config.confirmModulesPurge=false in non-interactive environments.

Thank you for your attention to this issue!

[KSXGitHub]

I can't reproduce. Can you provide a minimal code that produces this behavior? Ideally as a git repo.

[wagenet]

I'm seeing the issue too. It may require workspaces.

[octogonz]

@zkochan I've been experiencing the same problem. It seems to be caused by this code:

https://github.com/pnpm/pnpm/blob/bc83798d469e1b343081704bbe99087833cf79bd/pkg-manager/get-context/src/index.ts#L328-L336

My exact command line was (PNPM 8.7.6):

pnpm install --store C:\Caches\RushPnpmStore\ --strict-peer-dependencies --recursive --link-workspace-packages=false --frozen-lockfile=false

Some questions:

1. Why is pnpm install trying to prompt for input from STDIN?

2. Under what conditions can that happen?

3. For commands such as pnpm install which have always been used by automation scripts, how can we guarantee that they will never prompt for user input? (I feel like we need a guarantee, not a heuristic that tries to guess whether STDIN is a TTY or the environment variables look like a familiar CI company.)

[octogonz]

I can't reproduce. Can you provide a minimal code that produces this behavior? Ideally as a git repo.

@ksxgithub Looking more closely at the code, PNPM's implementation does use heuristics to try to guess whether PNPM might be invoked in a CI system or not:

https://github.com/pnpm/pnpm/blob/bc83798d469e1b343081704bbe99087833cf79bd/pkg-manager/get-context/src/index.ts#L123

Therefore to repro this problem, we simply need to ensure that isCI is false. In my case above, it happened like this:

• RushJS is invoked by a human from an interactive shell (via the rush build command)
• Rush spawns a subprocess that does pnpm install (this happens during rush build because we are building a particular project in the monorepo, whose purpose is to test pnpm install of library packages)
• The subprocess's STDIN is connected to the TTY shell of the Rush parent process
• But the subprocess's STDOUT is connected to a "stream collator" that buffers the output, so it is not visible to the end user during building.

Initially I had thought that the installation was "frozen", but actually PNPM has printed Proceed? (Y/n) » ? and is waiting for an answer. During this "frozen" state, we could actually unblock it by typing Y, but the user doesn't know to do that because we can't see the prompt message.

We should probably improve Rush to disconnect STDIN in this situation. But nonetheless, the script that invokes pnpm install was never designed with an expectation that it might try to prompt the end user for input. That is not ever a good behavior for an automated test.

Thus, we nonetheless need a way to guarantee that PNPM will not try to read from STDIN, when it is being invoked by automation scripts, regardless of whether that script is running in a CI environment or not.

@dmichon-msft @iclanton

[octogonz]

Also, this message is apparently getting printed 5 times due to parallelism of --recursive across the 5 workspace projects: 🫠

[octogonz]

I found that disconnecting STDIN using stdio:[ 'ignore', 'inherit', 'inherit'] does prevent PNPM from freezing. However:

• This does NOT prevent PNPM from printing the Proceed (Y/n) prompts.
• And the default answer is "no", so the result is a broken installation.

Adding --config.confirmModulesPurge=false does fix the problem. However is a poor solution. What if in the future PNPM decides to introduce 3 other questions that get asked during pnpm install? Do we need a --config._____=false setting to suppress each one? It would be better to have a --no-interactive switch that blocks all prompting of any kind, and/or an environment variable that can be inherited by all subprocesses as well.

CC @zkochan

[miklschmidt]

I just ran into this too. --no-interactive would be much appreciated.

[sanabel-al-firdaws]

i was wondering why Tina cms dosen't allow for pnpm as package manger for there Docusaurus starter

maybe because when using pnpm with github actions you have to install it + --no-interactive isn't an option like npm and yarn i gusse i will be using yarn for now

[octogonz]

maybe because when using pnpm with github actions you have to install it + --no-interactive isn't an option like npm and yarn i gusse i will be using yarn for now

@abdullhakim-sami The situation is not so bad as that. Just to clarify, PNPM uses the ci-info heuristic to try to guess whether it is running in a CI environment, which does successfully detect most environments. And although --config.confirmModulesPurge=false is not an intuitive CLI experience, it does technically provide the same functionality as --no-interactive. In other words, this GitHub issue is really about ergonomics rather than functionality.

Given that the necessary behavior is already implemented by confirmModulesPurge, it should be relatively easy for someone to make a PR to expose a --no-interactive switch. Which we should probably name "--non-interactive" since on closer inspection that's what Yarn has named it.

[weyert]

Yeah, I think alternatively you could also add ENV CI=1 to the Dockerfile?

[HermanBide]

has this issue been solved?

[mihob]

any news on this issue?

[fcsonline]

I think as @octogonz proposal, but as workaround, I will come here with a hack (sorry about that), but it can help:

yes | pnpm install --frozen-lockfile