Running Packages with npx — Node.js

Using npx

npx runs a package's executable without installing it permanently. It is how you scaffold a project (npx create-next-app), run a one-off tool, or execute a locally-installed binary by name. Bundled with npm since 5.2, it closed a real gap: previously, running a CLI meant either a global install or digging into node_modules/.bin by hand.

What npx does, in order

When you run npx <command>, it resolves the command through a clear priority chain:

npx resolution order

Text

npx some-tool
   1. Is "some-tool" in ./node_modules/.bin?  → run the local copy
   2. Is it already in the npx cache?           → run that
   3. Otherwise → download it to a temp cache, run it, keep it cached
                  (nothing is added to your package.json)

Local-first is the key behavior

Inside a project, `npx tsc` runs *your project's* installed TypeScript — the exact version pinned in your lockfile — not a global one. This guarantees everyone runs the same tool version. Only if no local copy exists does npx reach out to the registry.

The three everyday uses

Use case	Example
Scaffold a new project	`npx create-next-app@latest my-app`
Run a local tool ad-hoc	`npx eslint .` (uses your installed eslint)
Try a tool once, no install	`npx cowsay hello`

Bash

npx create-next-app@latest my-app   # scaffolder — run once, never kept around
npx tsc --noEmit                     # run the project's local TypeScript
npx prettier --write .               # format without a global install
npx http-server                      # spin up a quick static server

Why “run once” tools shine here

Scaffolders like create-next-app are used exactly once per project. Installing them globally means a stale version sits on your machine forever. npx ...@latest fetches the current version each time, runs it, and never pollutes your global space:

Pin the version for reproducible scaffolds

`npx create-next-app` may resolve to a cached older copy, while `npx create-next-app@latest` forces the newest. For CI or documented setup steps, pin explicitly — `npx create-next-app@14.2.0` — so the result is identical for everyone, not "whatever was latest the day they ran it".

Useful flags

Flag	Effect
`-y` / `--yes`	Skip the "install this package?" confirmation prompt
`--no` / `--no-install`	Fail instead of downloading if not already present
`-p <pkg>`	Install one package but run a differently-named binary from it
`-c "<cmd>"`	Run a command string inside the npx-augmented PATH
`--package=pkg@ver`	Pin the exact package version to execute

The -p form matters when the package name and the command it provides differ:

Bash

npx -p typescript tsc --version    # package "typescript", binary "tsc"

npx vs a global install

	`npx tool`	`npm i -g tool`
Version freshness	Latest (or pinned) each run	Frozen until you update it
Disk footprint	Temp cache, prunable	Permanent global install
Reproducibility	High with `@version`	Drifts across machines
Best for	One-offs, scaffolds, local bins	Daily-driver CLIs you run constantly

npx runs code from the registry — name-typo with care

Because `npx foo` will *download and execute* `foo` if it is not local, a typo can run an attacker's typosquatted package with your privileges. Double-check names on first use, prefer `--no-install` in scripts where the tool should already be present, and pin versions. Same supply-chain caution as any install — see [Dependency & Secret Security](/nodejs/dependency-security).

When you *do* want a tool installed permanently and on your PATH everywhere: [Global Packages](/nodejs/global-packages).