What is npx and how does it differ from a global install?

Q: What is npx and how does it differ from a global install?

**Target Audience:** Engineers preparing for Node.js/npm tooling interviews. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The local-resolution behavior below was **actually run** — a real resolved file path, and a real, immediately-checked `npm ls -g` confirming nothing was installed globally, not a description of intended behavior. ## 1. Why This Even Matters — A Story First Borrowing a specific tool from a shared toolbox for one job, and returning it immediately after, leaves nothing extra cluttering your own garage. Buying that same tool and keeping it permanently on your own shelf — useful if you need it constantly, but genuinely unnecessary clutter, and now a DIFFERENT tool on a DIFFERENT shelf than whatever a teammate happens to own, for a job that was really a one-off. `npx` is the borrowing; `npm install -g` is the permanent purchase. ## 2. The Core Idea 📌 **Interview ter

01

Understand the problem

Question presented to candidate: "A teammate suggests "just npm install -g this-tool" to run a one-off CLI, but you'd rather not pollute your global npm setup or worry about version drift across machines. What's the alternative, and what does it actually do differently?"

What a strong answer should cover:

npx runs a package's binary — it does not, by itself, require installing anything globally or persistently. Given a package already present as a local project dependency, npx <name> resolves and runs that local copy directly; given a package not present locally, npx fetches and runs it in a temporary cache, without adding a lasting global install.
📌 Verified, not assumed: in a real project with a single bin entry declared in its own package.json (no separate dependency install even needed for this specific case), npx my-local-cli genuinely ran the local project's own script — confirmed by its real, actual resolved file path in the output — while a real npm ls -g immediately afterward genuinely showed nothing installed globally.
The core problem this solves, precisely matching the prompt: a global install (npm install -g) is persistent and shared system-wide — every project on the machine sees the identical global version, which genuinely causes real version drift between projects/machines/CI (one project needing an older CLI version than another, or a CI environment lacking whatever was manually installed globally on a developer's laptop). npx sidesteps this by preferring the project-local, version-pinned copy (declared in that project's own package.json/lockfile) — reproducible per-project, per-clone, per-CI-run, with no manual global setup step at all.
A precise answer names the project-local-first resolution as the single most important behavior: if a CLI is already listed as a project dependency (even a devDependency), npx <name> finds and runs that exact locally-installed, version-locked copy rather than reaching out anywhere else — this is different from, and safer than, assuming npx always means "download something fresh from the registry."
The honest scope: for a package genuinely not present locally at all, npx does reach out to the registry and runs a temporarily-cached copy — this is real, useful for a genuine one-off tool, but it is not magic offline resolution; it still needs registry/network access for that specific case, unlike the verified local-resolution case which needs none.

Clarifying questions expected:

"Is this tool something the project genuinely depends on repeatedly (belongs as a real devDependency, run via npx), or a genuine one-off never needed again?" — shapes whether it belongs in package.json at all versus an ad hoc npx run.
"Does this need to work identically and reproducibly across CI, without relying on anything manually pre-installed on a given machine?" — the core reason to prefer npx-of-a-local-dependency over a global install in the first place.

Code / implementation expected: Yes — a real project resolving and running its own local binary via npx, with a real, immediately-checked confirmation that nothing was installed globally, is the concrete, convincing proof of exactly what npx does and does not do.

nodejsnpmnpxtooling

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for Node.js/npm tooling interviews. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The local-resolution behavior below was actually run — a real resolved file path, and a rea

Solution ready — 2 min read

Classified // press E to declassify

04

Read the code

A real project with a local bin: npx resolves and runs it directly, with zero global install

# package.json
# { "name": "npx-demo", "bin": { "my-local-cli": "./cli.js" } }
#
# cli.js:
# #!/usr/bin/env node
# console.log("my-local-cli ran from:", __filename);

$ npm install
$ npx my-local-cli
my-local-cli ran from: C:\...\q5-npx\cli.js

# confirm nothing was installed globally, immediately afterward:
$ npm ls -g my-local-cli
C:\Users\...\AppData\Roaming\npm
`-- (empty)

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.