What / Why

I have been trying to test npm 7 with the npm_config_node_gyp env var set, or doing npm config set node-gyp=some_path. It isn't working. I believe I've traced back the problem to a basically hard-coded value here:

By the way: Editing that (probably too simplistically) to the following makes it configurable again with the env var:

const npm_config_node_gyp = process.env.npm_config_node_gyp || require.resolve('node-gyp/bin/node-gyp.js')

When

Any time I try to use a custom location of node-gyp with the npm_config_node_gyp env var or after doing npm config set node-gyp=path/to/node-gyp/bin/node-gyp.js with npm 7.

Where

Any npm command I run that should run node-gyp to rebuild native code is affected.

How

Current Behavior

npm 7 always always runs its built-in copy of node-gyp. (Or, if there is a copy of node-gyp as a top-level dependency in the current project's node_modules folder, that copy from the local node_modules/node-gyp folder is used.)

Steps to Reproduce

Set up a project with native C++ code somewhere in the dependencies and try to get npm to run node-gyp on it. Example steps below, and example output below that:

• Clone or download node-gyp to your computer somewhere, install its dependencies
• Set the environment variable npm_config_node_gyp to /path/to/node-gyp/bin/node-gyp.js.
  • OR Set npm config set npm-config=/path/to/node-gyp/bin/node-gyp.js
• Set up a new npm project with mkdir x && cd x && npm init -y && npm install [some package that needs to build native C++ code]
• Make sure you're running npm 7 for the next step...
• Run npm ci --verbose --foreground-scripts to see verbose output, including the path node-gyp is at.

[...]
> node-gyp rebuild

gyp info it worked if it ends with oko run [email protected] install node_modules/tree-sitter-carp node-gyp rebuild
gyp verb cli [
gyp verb cli   '/Users/[user]/n-prefix/bin/node',
gyp verb cli   '/Users/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js',
gyp verb cli   'rebuild'
gyp verb cli ]
gyp info using [email protected]
[...]

> node-gyp rebuild

gyp info it worked if it ends with oko run [email protected] install node_modules/tree-sitter-carp node-gyp rebuild
gyp verb cli [
gyp verb cli   '/Users/[user]/n-prefix/bin/node',
gyp verb cli   '/Users/[user]/node-gyp/bin/node-gyp.js',
gyp verb cli   'rebuild'
gyp verb cli ]

Expected Behavior

• The path/copy of node-gyp that runs should be configurable, as it has been in npm 6, and as all the code/documentation seems to imply will work.

Who

• n/a

References

• n/a

run-script uses JSON.stringify to quote/escape command arguments:

However, shells don't use the same quoting rule as JSON, which leads to incorrect behavior. In particular, literal newline characters (NL) get converted to \n (BACKSLASH N) by JSON.stringify, but bash does not treat \n as an escape sequence, and as a result the script receives \n (BACKSLASH N) as its argument.

To fix this problem, shell escaping should be used instead of JSON stringify.

I ran into this calling a script that invokes webpack with a --define argument containing a literal newline (NL) character. npm 7 converts this to a \n, which results in webpack substituting invalid javascript code leading to a parse error.

npm/run-script currently uses an older version of node-gyp that in turn has a dependency on the deprecated package request. By upgrading to the newly released version 8.0.0 of node-gyp (which now uses fetch instead), we can get rid of many deprecation messages stemming from any packages dependent on run-script.

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When running NPM scripts concurrently, some will fail with errors like:

• /tmp/ *** .sh: Text file busy
• Error: ETXTBSY: text file is busy, open '/tmp/ *** .sh'

Expected Behavior

NPM scripts run as expected when run concurrently by using unique filenames.

The current implementation is:

const fileName = escape.filename(`${event}-${Date.now()}`)

Unfortunately, when two scripts run at the same time with the same filename due to Date.now(), NPM will error. Instead, files should be named uniquely. In the NPM cli, this implementation avoids the error:

const rand = require('crypto').randomBytes(4).toString('hex')

Steps To Reproduce

1. With the latest version of NPM
2. Run two NPM scripts at the exact same second
3. Log error

Environment

• npm: 8.13.2
• Node: v16.15.0
• OS: Ubuntu 20.04
• platform: GitHub Actions

What / Why

Can not build binary packages on Debian 9 (Stretch) using NPM and Node 16..

Debian 9 (Stretch) comes with Python 3.5.
It is in LTS mode until the end of June 2022.

Node-Gyp version 8 requires Python 3.6 and above.
That was introduced when support for Python 2 was dropped.

With feat: update to node-gyp@8 support for Debian 9 was inadvertently dropped.

When

When using nodejs official docker image any npm install that requires building a binary package will fail.

Problem extends to any out-of-the box Debian 9 (Stretch).

Where

Node 16 and Debian 9 (Stretch)

How

Current Behavior

node-gyp can not find suitable python.

Specifically:

gyp ERR! find Python - version is 3.5.3 - should be >=3.6.0
gyp ERR! find Python - THIS VERSION OF PYTHON IS NOT SUPPORTED

Log (from GH Actions run specified below):

gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | linux | x64
gyp ERR! find Python 
gyp ERR! find Python Python is not set from command line or npm configuration
gyp ERR! find Python Python is not set from environment variable PYTHON
gyp ERR! find Python checking if "python3" can be used
gyp ERR! find Python - executable path is "/usr/bin/python3"
gyp ERR! find Python - version is "3.5.3"
gyp ERR! find Python - version is 3.5.3 - should be >=3.6.0
gyp ERR! find Python - THIS VERSION OF PYTHON IS NOT SUPPORTED
gyp ERR! find Python checking if "python" can be used
gyp ERR! find Python - executable path is "/usr/bin/python"
gyp ERR! find Python - version is "2.7.13"
Failed to execute '/usr/local/bin/node /usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js configure --fallback-to-build --module=/__w/appoptics-bindings-node-dev/appoptics-bindings-node-dev/dist/napi-v7/apm_bindings.node --module_name=apm_bindings --module_path=/__w/appoptics-bindings-node-dev/appoptics-bindings-node-dev/dist/napi-v7 --napi_version=8 --node_abi_napi=napi --napi_build_version=7 --node_napi_label=napi-v7' (1)
gyp ERR! find Python - version is 2.7.13 - should be >=3.6.0
gyp ERR! find Python - THIS VERSION OF PYTHON IS NOT SUPPORTED
gyp ERR! find Python 
gyp ERR! find Python **********************************************************
gyp ERR! find Python You need to install the latest version of Python.
gyp ERR! find Python Node-gyp should be able to find and use Python. If not,
gyp ERR! find Python you can try one of the following options:
gyp ERR! find Python - Use the switch --python="/path/to/pythonexecutable"
gyp ERR! find Python   (accepted by both node-gyp and npm)
gyp ERR! find Python - Set the environment variable PYTHON
gyp ERR! find Python - Set the npm configuration variable python:
gyp ERR! find Python   npm config set python "/path/to/pythonexecutable"
gyp ERR! find Python For more information consult the documentation at:
gyp ERR! find Python https://github.com/nodejs/node-gyp#installation
gyp ERR! find Python **********************************************************
gyp ERR! find Python 
gyp ERR! configure error 
gyp ERR! stack Error: Could not find any Python installation to use

Steps to Reproduce

Pull image:
docker run -it -w /usr/src/work node:16-stretch bash

npm install @appoptics/apm-bindings --build-from-source

npm install canvas --build-from-source

etc.

Expected Behavior

As was before update to node-gyp@8 - node-gyp can find suitable python.

gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | linux | x64
gyp info ok 
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | linux | x64
gyp info find Python using Python version 3.5.3 found at "/usr/bin/python3"
gyp http GET https://nodejs.org/download/release/v16.9.1/node-v16.9.1-headers.tar.gz
gyp http 200 https://nodejs.org/download/release/v16.9.1/node-v16.9.1-headers.tar.gz
gyp http GET https://nodejs.org/download/release/v16.9.1/SHASUMS256.txt
gyp http 200 https://nodejs.org/download/release/v16.9.1/SHASUMS256.txt

Who

• n/a

References

• Real life multi OS test run: https://github.com/appoptics/appoptics-bindings-node/actions/runs/1409965377
• Failure on node:16-stretch image: https://github.com/appoptics/appoptics-bindings-node/runs/4073765970?check_suite_focus=true
• Success on node:16-bullseye image: https://github.com/appoptics/appoptics-bindings-node/runs/4073766006?check_suite_focus=true

What / Why

In an npm package.json script on Windows, \n gobbles the rest of the command.

When

• A package.json script contains \n

Where

• npm scripts declared in package.json

My environment is:

• Windows PowerShell 5.1.18362.752
• npm 6.14.6
• node v12.18.4

How

Current Behavior

Everything until the \n is executed. Everything after the \n is ignored.

Steps to Reproduce

In package.json:

{
  "scripts": {
    "bad": "echo a\nb && echo c"
  }
}

In Windows Powershell:

npm run bad

Output (note that everything except the last line is a reprint of the command, so really the command's output is just "a"):

> [email protected] bad C:\My\Location
> echo a
b && echo c

a

Expected Behavior

\n is a common sequence when writing scripts for Mac or Linux, so I expect it not to break unrelated parts of the script when running on Windows. \n could be treated literally, which is the normal PowerShell behavior, or it could be treated like the empty string, `n (the Powershell newline sequence), or n.

Who

• n/a

References

• May be a bug in npm/read-package-json, rather than a bug in npm/run-script. I have cross-posted there.

Hello!

I hope you are doing well!

We are a security research team. Our tool automatically detected a vulnerability in this repository. We want to disclose it responsibly. GitHub has a feature called Private vulnerability reporting, which enables security research to privately disclose a vulnerability. Unfortunately, it is not enabled for this repository.

Can you enable it, so that we can report it?

Thanks in advance!

PS: you can read about how to enable private vulnerability reporting here: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

v3.0.1 includes node-gyp 9 in #52, but this was a breaking change, because node-gyp 9 requires node 12.22, and run-script v3.0.0 only require node v12.13.

Can that update be reverted in a v3.0.3?

Expected Behavior

No response

Steps To Reproduce

No response

Environment

No response

What / Why

I want to display all build logs in terminal when I run npm run build command
but now I only saw error when throw errors...i can't see any build details in terminal

If you install @npmcli/run-script in an empty folder npm will warn about three deprecated libraries:

> npm i @npmcli/run-script
npm WARN deprecated [email protected]: this library is no longer supported
npm WARN deprecated [email protected]: Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

This is because of:

AFAICS if one would update node-gyp to version 8 all these warnings would go away, since node-gyp no longer uses request, which uses har-validator and uuid as sup-dependencies.

See https://github.com/nodejs/node-gyp/blob/master/CHANGELOG.md#v800-2021-04-03 for the changelog of node-gyp version 8.

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When running nested npm commands like implicit pre and post scripts (pretest, prepack, preinstall...), they are run on new spawned processes, with the only reference to where they start by the process banner, but there's no indication of where they end or their relationship, since output is flat.

Expected Behavior

I would like that when a npm command is exec as direct or indirect result of a previous npm command, that its output gets indented, so it's easier to see where they start and end and who's its parent npm process. To do it, we would need to do:

1. detect we are running as a nested npm command, if not proceed as usual.
2. use https://nodejs.org/api/tty.html or https://nodejs.org/api/readline.html to create a virtual TTY where to run the command, instead of using inherit. Also handle the resize event, and maybe mimic someway the commands they are not running on a TTY if the parent process doesn't does it.
3. process the output to the stdout and stderr of the virtual TTY, and indent it for each new newline that arrives

Steps To Reproduce

No response

Environment

• npm: 9.6.7
• Node: v20.3.1
• OS: Ubuntu Linux 23.04
• platform: x86_64

What / Why

This code assumes that add is only ever called with an object with a once method:

In fact, add is called with undefined in a Docker container when running any script. (I'm not sure what about the Docker environment causes this.) See repro instructions below.

When

Repros consistently.

Where

• n/a

How

• n/a

Current Behavior

When running any script, npm raises the following error:

23 verbose stack TypeError: Cannot read property 'once' of undefined
23 verbose stack     at Object.add (/usr/local/lib/node_modules/npm/node_modules/@npmcli/run-script/lib/signal-manager.js:36:8)
23 verbose stack     at runScriptPkg (/usr/local/lib/node_modules/npm/node_modules/@npmcli/run-script/lib/run-script-pkg.js:63:19)
23 verbose stack     at runScript (/usr/local/lib/node_modules/npm/node_modules/@npmcli/run-script/lib/run-script.js:8:16)
23 verbose stack     at runScript (/usr/local/lib/node_modules/npm/lib/run-script.js:77:11)

Steps to Reproduce

Create a Dockerfile containing:

FROM node:14.14

RUN npm install --global [email protected]

WORKDIR /app

RUN npm init -y
RUN npm test || exit 0
RUN cat /root/.npm/_logs/*.log

Then, run docker build ..

Expected Behavior

An error should not be raised.

Who

• @isaacs @nlf

References

• n/a

What is the purpose of this decision?

What / Why

After Windows 10’s April 2018 Update, directories can be set as case-sensitive
So being a case-sensitive directory, you cannot execute batch files ( or any executable in general) by skipping the extensions
Thus while specifying the npm package executable inside scripts, .cmd should be explicitly specified, otherwise it doesn't work.
But if I specify it explicitly, the package no longer works cross-platform.

How

Current Behavior

• Since there already exists an 'extension-less' browserslist file, the spawn process passes that to cmd.exe, and that in turn doesn't recognize that as an windows executable, almost as if the file doesn't exist. start command explicitly outputs that error.

> [email protected] build
> browserslist --version

'browserslist' is not recognized as an internal or external command,
operable program or batch file.

Steps to Reproduce

• Create a directory, set it as case-sensitive using the command fsutil.exe file setCaseSensitiveInfo <path> enable
• Create a package config which has dependencies to any npm package with install script, e.g. browserslist

{
  "name": "client_app",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "demo": "browserslist --version"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "browserslist": "^4.16.5"
  }
}

• npm run demo

Expected Behavior

• It should print the version of browserslist

> [email protected] build
> browserslist.cmd --version

browserslist 4.16.5

If this is recognized as package issue instead of an OS issue, then I can attempt to make necessary changes to make-spawn-args file to fix this.

What / Why

#9 introduced an issue whereby an error is thrown when an npm script process is terminated.

When

Consistently, following the repro below.

Where

Any project. macOS 10.15.7, Node 14.14.0, npm 7.0.6.

How

• n/a

Current Behavior

This line assumes that the callback will always be invoked with an object:

However, this is evidently not the case:

21 verbose stack TypeError: Cannot destructure property 'code' of 'object null' as it is null.
21 verbose stack     at ChildProcess.<anonymous> (/Users/billy/.config/nvm/14.14.0/lib/node_modules/npm/node_modules/@npmcli/run-script/lib/signal-manager.js:36:24)
21 verbose stack     at Object.onceWrapper (events.js:422:26)
21 verbose stack     at ChildProcess.emit (events.js:315:20)
21 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12)

Steps to Reproduce

1. Create a package.json with a script foo that includes a long-running process.
2. Run npm run foo.
3. Terminate the script early, e.g., by pressing ctrl+c.

Expected Behavior

The process should terminate without throwing an error, or at least by throwing a more intelligible error.

Who

@nlf, @isaacs

References

• Introduced in #9.

What / Why

n/a

import runScript from '@npmcli/run-script';
(async () => {
	let path = 'xxxx\\test\\res\\pkg-a';
	await runScript({
		event: 'pretest',
		path,
		stdioString: true,
		stdio: 'inherit',
	})
		.then((ret) =>
		{
			console.dir(ret)
		})
		.catch((e) =>
		{
			console.trace(e)
		})
	;
	await runScript({
		event: 'test',
		path,
		stdioString: true,
		stdio: 'inherit',
	})
		.then((ret) =>
		{
			console.dir(ret)
		})
		.catch((e) =>
		{
			console.trace(e)
		})
	;
})();

{
  "name": "pkg-a",
  "scripts": {
    "pretest": "echo pretest && npm init",
    "test": "echo test",
  }
}

When

• n/a

Where

• n/a

How

when npm init is ask input
send a ctrl + c ending it

Current Behavior

• n/a

> pkg-a@1.0.0 pretest
> echo pretest && npm init
pretest
This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help json` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (pkg-a) npm WARN init canceled
{
  cmd: 'C:\\WINDOWS\\system32\\cmd.exe',
  args: [ '/d', '/s', '/c', '"echo pretest && npm init"' ],
  code: 0,
  signal: null,
  stdout: '',
  stderr: '',
  event: 'pretest',
  script: 'echo pretest && npm init',
  pkgid: '[email protected]',
  path: 'test\\res\\pkg-a'
}
> pkg-a@1.0.0 test
> echo test
test
{
  cmd: 'C:\\WINDOWS\\system32\\cmd.exe',
  args: [ '/d', '/s', '/c', '"echo test"' ],
  code: 0,
  signal: null,
  stdout: '',
  stderr: '',
  event: 'test',
  script: 'echo test',
  pkgid: '[email protected]',
  path: 'test\\res\\pkg-a'
}

Expected Behavior

• n/a

can know user is send ctrl + c from return message

Who

• n/a

References

• n/a

What / Why

Migrating to node-gyp v8 would remove the package request which has multiple warnings related to it.
Related PR nodejs/node-gyp#2220

• a warning about usage of older Math.random()

npm WARN deprecated [email protected]: Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details.

• a warning about no longer maintained package har-validator usage

npm WARN deprecated [email protected]: this library is no longer supported

• a warning about the package itself (request) being deprecated

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

When

• n/a

Where

• n/a

How

Current Behavior

• n/a

Steps to Reproduce

• n/a

Expected Behavior

• n/a

Who

• n/a

References

• n/a

What / Why

From npm 7.0.12, a start script receives ['a', 'b'] as argv from npm start -- a "" b ,
while receiving ['a', '', 'b'] in <= 7.0.11 or 6.14.9.

I could not find any workaround.

When

• Whenever I run a start script with an empty argument.
  • This is usual use case for me when using internal-use cli tools.

Where

• npm >= 7.0.12
• Node: 15.13.0
• OS: Windows 10 Pro 2004 (19041.630)
• cmd.exe command prompt

How

Steps to Reproduce

package.json

{
  "scripts": {
    "start": "node index.js"
  }
}

index.js

console.log(process.argv.slice(2));

then,

npm start -- a "" b

Current Behavior

npm 7.0.12 - 7.0.15, 7.1.0 print

[ 'a', 'b' ]

Expected Behavior

should print

[ 'a', '', 'b' ]

as npm 6.14.9, 7.0.11 do.

Who

• n/a

References

• npm/cli#2249

Locally modifying

--- make-spawn-args.js.orig
+++ make-spawn-args.js
@@ -10,7 +10,7 @@
   const parsed = ShellString.sh([cmd])
   for (const child of parsed.children) {
     if (child instanceof ShellStringText) {
-      const children = child.contents.filter(segment => segment !== null).map(segment => quoteForShell(segment, false, isWindows && 'win32'))
+      const children = child.contents.map(segment => segment == null ? '' : segment).map(segment => quoteForShell(segment, false, isWindows && 'win32'))
       result.push(...children)
     } else if (child instanceof ShellStringUnquoted) {
       result.push(child.value)

produces expected behavior, but I don't know it is correct.

see: npm/cli#52

Investigate using puka to quote arguments, rather than what we're doing now.

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Within the last 2 hours, the package seems to have disappeared from the registry, or been made private. As cannot access via the browser either:

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@npmcli%2frun-script - Not found
npm ERR! 404 
npm ERR! 404  '@npmcli/[email protected]' is not in this registry.

Expected Behavior

To be available

Steps To Reproduce

1. Try install this package

Environment

• npm: 8.11.0
• Node: 18.3.0
• OS: PopOS 20.04
• platform: Local and in CI (Github)

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

On Windows, if Bash/sh is set as script-shell for npm and a script is run, it gives the following error:

/usr/bin/bash: C:UsersMeAppDataLocalTempmy-script-1656497236474.sh: command not found

It appears that backslashes in paths are not escaped or paths transformed.

This bug is likely introduced in run-script 4.1.0:

write scripts to a file and run that instead of passing scripts as a single string 24c5165

Expected Behavior

It should run the script fine

Steps To Reproduce

1. Install npm 8.13.0 or later
2. Put some script in a packages.json, "the-script": "echo hi" will do
3. Run npm config set script-shell "C:\Program Files\Git\bin\sh.exe" if you have Git installed, or use the path to sh/bash for your MSYS2 installation
4. Run npm run the-script
5. Get the error shown above

Environment

• npm: 8.13.0, 8.13.1 (8.12.2 and below work fine)
• Node: 18.4.0
• OS: Windows 10

What / Why

For usage within typescript code.

If they already exists I apologize, its really hard to search for anything related to npmcli because google just sends you to the repo site.

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When using [email protected] with @npmcli/[email protected] on AIX (Node.js 14.20.0) postinstall scripts do not run because the default shell command sh (which is an alias for the Korn shell ksh) does not support the -- syntax:

$ uname
AIX
$ oslevel -s
7200-05-03-2148
$ sh -c -- echo hello world
echo: --:  not found
$ ksh -c -- echo hello world
echo: --:  not found
$ ksh93 -c -- echo hello world

This causes failures whenevere a postinstall, or indeed any, lifecycle script needs to be run

> @my-enterprise/[email protected] postinstall
> npm list || echo done

npm list || echo done: --:  not found
npm ERR! code 127
npm ERR! path /build/jenkins/slot0/product-build/nodejs
npm ERR! command failed
npm ERR! command sh -c -- npm list || echo done

npm ERR! A complete log of this run can be found in:
npm ERR!     /build/jenkins/slot0/.npm/_logs/2022-08-11T03_41_16_217Z-debug-0.log

Expected Behavior

I expect npm to be able to run scripts on AIX without having to install Bash and set the script-shell setting on every machine.

Steps To Reproduce

1. On AIX with Node.js v14.20.0, [email protected] and @npmcli/[email protected]
2. Without script-shell set
3. Create a new package and add a script

   "scripts": {
     "hello": "echo hello world"
   },
   

4. Run npm run hello and observe it fails with

   $ npm run hello
   
   > [email protected] hello
   > echo hello world
   
   echo hello world: --:  not found
   

Environment

• npm: 8.17.0
• Node: 14.20.0
• OS: AIX 7.2 TL3
• platform: AIX

Apparently the resulting JSON value of:

https://github.com/npm/cli/blob/8806015fdd025f73ccf4001472370eafd3c5a856/test/lib/rebuild.js#L36-L45

Resolves to: {"name":"a","version":"1.0.0","bin":"cwd","scripts":{"preinstall":"node -e 'require(\\"fs\\").writeFileSync(\\"cwd\\", \\"\\")'"}}

is not working as expected after updating to @npmcli/[email protected] - for now we decided to postpone the update in npm/cli until we confirm whether this was an error in the test there or a unwanted breaking change from the refactor removing puka.

Here's an example of a failed build:

https://github.com/npm/cli/runs/2069643968

cc @nlf