pnx

Aliases: pnpm dlx, pnpx

Fetches a package from the registry without installing it as a dependency, hotloads it, and runs whatever default command binary it exposes.

For example, to use create-vue anywhere to bootstrap a Vue project without needing to install it under another project, you can run:

pnx create-vue my-app

This will fetch create-vue from the registry and run it with the given arguments.

You may also specify which exact version of the package you'd like to use:

pnx create-vue@next my-app

The catalog: protocol is also supported, allowing you to use versions defined in your workspace catalogs:

pnx shx@catalog:

Running a package manager or a runtime#

Added in: v12.0.0-rc.6 (pnpm v12 only)

Naming one of the package managers pnpm provisions (pnpm, npm, yarn, bun), or a runtime (node, deno, bun), provisions the real thing instead of installing the npm package that shares its name:

pnx yarn@4 install
pnx npm@11 ci
pnx bun@1.3.0 install
pnx node@22 --version

The npm packages with those names are either a different line of the tool or a wrapper that downloads it. For example, Yarn 4 is published as @yarnpkg/cli-dist, so pnx yarn@4 runs Yarn 4 itself, and pnx node@22 runs that Node.js release.

A specifier that locates a package rather than asking for a released version installs what it names, unchanged:

pnx yarn@npm:yarn@1.22.22
pnx yarn@yarnpkg/berry

--package naming a package manager picks which of its commands to run:

pnx --package npm@11 npx create-something

Running a Rust release#

Added in: v12.11.1

--package=rust@<channel> runs a tool of that Rust toolchain release, such as cargo or rustc. pnpm installs the release into the store first. The channel is written the way rust-toolchain.toml writes it, and a bare rust means stable.

pnx --package=rust@nightly-2026-01-01 cargo build --target wasm32-unknown-unknown

The release gets the profile, components, and targets of the rust-toolchain.toml that governs the current directory, plus the target of each --target argument.

Options#

--package <name>#

The package to install before running the command.

Example:

pnx --package=@pnpm/meta-updater meta-updater --help
pnx --package=@pnpm/meta-updater@0 meta-updater --help

Multiple packages can be provided for installation:

pnx --package=yo --package=generator-webapp yo webapp --skip-install

--allow-build#

A list of package names that are allowed to run build scripts during installation.

Example:

pnx --allow-build=esbuild my-bundler bundle

The actual packages executed by pnx are allowed to run build scripts by default. So if in the above example my-bundler has to be built before execution, it will be built.

When a dependency's build scripts are skipped, pnx prompts you to approve them in an interactive terminal. This also applies when reusing a cached install that still has builds awaiting approval. Approved scripts run before the requested command.

Approval decisions are saved in the isolated pnx cache. They do not change the calling project's build settings.

Without an interactive terminal, unapproved build scripts remain skipped. Use --allow-build to allow the dependencies whose scripts the command needs.

--shell-mode, -c#

Runs the command inside of a shell. Uses /bin/sh on UNIX and cmd.exe on Windows.

Example:

pnx --package cowsay --package lolcatjs -c 'echo "hi pnpm" | cowsay | lolcatjs'

--cpu, --os, --libc#

Choose which platform-tagged optional dependencies the pnx install keeps, by CPU architecture, operating system, and C library (glibc or musl). Repeat an option or separate values with commas:

pnx --cpu arm64,x64 --os linux some-cli

--silent, -s#

Only the output of the executed command is printed.

Security and trust policies#

pnx (and its pnpm dlx / pnpx aliases) honors the project-level security and trust policy settings when resolving and fetching the requested package:

This means pnx will refuse to execute freshly published or insufficiently trusted packages the same way a regular pnpm install would.