webpack-cli is the official command-line interface for webpack, the JavaScript module bundler; it parses your terminal commands and flags and hands them to webpack's core to run a build. Since webpack 4, the CLI was split into its own package, so webpack and webpack cli are separate installs that work together. It is easy to treat webpack-cli as invisible plumbing, but as a build-time dependency it runs with full access to your source and environment, which makes it worth understanding and securing.
What webpack-cli actually does
webpack the library is a bundler: it walks your import graph and produces optimized output. webpack-cli is the layer that lets you drive it from a shell. When you run webpack build or just webpack, it is webpack-cli that interprets the subcommand, reads flags, locates your config file, and invokes the compiler. It also powers scaffolding commands like webpack init and webpack info.
The split matters for a practical reason: installing webpack alone in a modern project and running the webpack command prompts you to install webpack-cli, because the binary lives in the CLI package.
Installing webpack-cli from npm
The standard install is as a dev dependency, since bundling happens at build time, not at runtime:
npm install --save-dev webpack webpack-cli
That gives you the webpack-cli npm package alongside webpack itself. Verify what landed:
npx webpack --version
# shows webpack, webpack-cli, and webpack-dev-server versions if present
Wire the build into your package.json scripts rather than calling the binary by path:
{
"scripts": {
"build": "webpack --mode production",
"dev": "webpack serve --mode development"
}
}
Running npm run build then resolves the local webpack-cli from node_modules/.bin, which is more reproducible than relying on a globally installed copy that may drift between machines.
Why a build tool is a security concern
It is tempting to think only runtime dependencies matter for security, but build-time packages like webpack-cli are arguably higher risk. They execute on developer laptops and in CI with access to source code, environment variables, and often deployment credentials. A compromised build dependency can inject malicious code into the very bundle you ship, poisoning every downstream user.
The JavaScript ecosystem has repeatedly seen this pattern: a popular package or one of its transitive dependencies gets hijacked, and the malicious version runs during npm install or the build. webpack-cli sits deep in most front-end toolchains and pulls in its own dependency tree, so the exposure is not just the one package but everything it resolves.
Two habits reduce the risk:
- Commit a lock file.
package-lock.jsonpins the entire resolved tree, including webpack-cli's transitive dependencies, so a fresh install cannot silently pull a different version. - Scan the dev-dependency tree, not just production. Many teams scope vulnerability scans to production dependencies and skip
devDependencies, which is exactly where webpack-cli lives. A software composition analysis run that includes dev dependencies is what catches a known-vulnerable transitive package under the CLI.
# See what webpack-cli drags in
npm ls webpack-cli
npm audit --omit=optional
Keeping webpack-cli up to date safely
Updating build tooling can break a build as readily as fix it, so treat CLI upgrades like any other dependency change: bump in a branch, run the full build and test suite, and diff the output bundle if you can. Avoid installing webpack-cli globally with -g; a global copy is shared across projects, drifts out of sync with per-project webpack versions, and is not captured by any single project's lock file. Local, lock-file-pinned installs are the reproducible choice.
When you do upgrade, read the release notes for breaking changes in flag names and config shape, which the webpack-cli project changes between majors more often than the webpack core does.
A quick mental model
Think of webpack-cli as the steering wheel and webpack as the engine. You interact with the wheel; the engine does the work. Neither is optional for a command-line build, and both run with real privileges over your code. Securing your front-end build means treating the CLI as a first-class dependency: pinned, scanned, and updated deliberately rather than casually.
FAQ
What is the difference between webpack and webpack-cli?
webpack is the bundler engine that processes your module graph; webpack-cli is the command-line interface that interprets your terminal commands and flags and invokes webpack. Since webpack 4 they are separate npm packages installed together.
How do I install webpack-cli?
Install both packages as dev dependencies: npm install --save-dev webpack webpack-cli. Then drive builds through package.json scripts so the local copy in node_modules/.bin is used.
Do I need webpack-cli if I have webpack?
If you run webpack from the command line, yes; the webpack binary lives in the webpack-cli package. Installing webpack alone will prompt you to add webpack-cli when you first run the command.
Is webpack-cli a security risk?
Like any build-time dependency, it runs with access to your source, environment, and CI credentials, and it pulls in a transitive tree. Pin it with a lock file and include dev dependencies when you scan for known vulnerabilities.