webpack-merge is a small, focused utility that combines webpack configuration objects by concatenating arrays and deep-merging objects, and it carries no known critical vulnerabilities, but its slow release cadence and the way it executes functions during merges are worth understanding before you lean on it. For anyone splitting a webpack setup into shared, development, and production configs, webpack merge is the standard tool. This guide explains what it actually does, its current maintenance signals, and how to keep it from becoming a soft spot in your build supply chain.
What webpack-merge Does
webpack-merge exposes a merge function that takes two or more configuration objects and produces a new combined object. Its merge semantics are the whole point: arrays are concatenated rather than overwritten, and objects are deep-merged. So a shared base config that lists a couple of loaders, merged with an environment config that adds another, yields all of them rather than one replacing the other. When it encounters functions, it executes them, runs the results through the merge algorithm, and wraps the returned values back in a function.
The canonical use is the classic three-file split:
const { merge } = require('webpack-merge');
const common = require('./webpack.common.js');
module.exports = merge(common, {
mode: 'production',
devtool: 'source-map',
optimization: { minimize: true }
});
That keeps shared configuration in one place and layers environment-specific settings on top without copy-paste drift. The library also offers mergeWithCustomize and strategy helpers for cases where the default concatenate-and-merge behavior is not what you want, for example when you need a later config to replace an array rather than append to it.
Maintenance Status: A Yellow Flag, Not a Red One
Here is the part that deserves attention. The latest published version is 6.0.1, and it has been a while since a new release. Package health tooling notes that webpack-merge has not shipped a new npm version in over twelve months, which by their heuristics can flag a project as receiving low maintainer attention or being effectively discontinued.
That signal calls for judgment, not panic. A tightly scoped utility that does one deterministic thing can be genuinely finished, needing no changes because its job has not changed. webpack-merge is close to that description. The risk with a low-cadence dependency is not that stable code suddenly breaks; it is that if a security issue is ever found, or if webpack's config schema shifts underneath it, a fix may be slow to arrive. For a build-time-only dependency like this, the blast radius of that risk is smaller than for a runtime library, but it is not zero, because your build pipeline is part of your software supply chain.
Where the Security Considerations Actually Live
webpack-merge runs at build time, not in your shipped application, so it is not exposed to end-user input the way a request handler is. That narrows the threat model considerably. The considerations that remain are about supply chain and config hygiene.
Treat config sources as trusted code. Because webpack-merge executes functions it finds in config objects, a merged config is executable code, not inert data. That is fine when every config file is yours and lives in version control. It becomes a problem if you ever build a config dynamically from an untrusted source, for example merging in a JSON blob fetched from somewhere at build time. Do not do that. Keep every input to merge under source control and code review.
Pin the version and lock it. Because releases are infrequent, pin webpack-merge to an exact version and commit your lockfile. That way a compromised or unexpected republish upstream cannot silently change what your build pulls in. Integrity hashes in package-lock.json give you tamper-evidence on the installed artifact.
Watch the whole build dependency tree. webpack-merge itself is small, but your build stack around it (webpack, loaders, plugins) is large and updates far more often. A build-time supply chain attack does not need to compromise your app code; poisoning a build dependency can inject malicious output into every artifact you ship. Scanning your devDependencies matters as much as scanning runtime ones. An SCA tool such as Safeguard covers both trees, so a flagged build-time package is not invisible just because it never runs in production. For the wider picture on hardening the build stage, our guide to building secure Node.js Docker images covers keeping dev tooling out of what you ship.
Practical Recommendations
Keep using webpack-merge if it fits; it is stable and does its job. Pin it to 6.0.1, commit your lockfile, and keep every config file it consumes in version control and under review. Monitor it as part of routine dependency scanning so that if an advisory ever appears against it or its transitive dependencies, you hear about it promptly. And review the maintenance signal periodically: if the project stays quiet and webpack's ecosystem moves on, keep an eye on whether the community consolidates around an alternative. For now, the low release cadence is a reason to monitor, not a reason to rip it out.
FAQ
Is webpack-merge safe to use?
Yes. It has no known critical vulnerabilities, runs only at build time, and does one well-defined job. The main caution is its infrequent release cadence, which means monitor it and pin the version, rather than any active flaw.
Why does webpack-merge get flagged as possibly discontinued?
Package health tools flag it because no new npm version has shipped in over a year. For a small, stable utility that can simply mean the code is complete, but it does mean any future fix could be slow, so treat it as a monitoring item.
Can webpack-merge run arbitrary code?
It executes functions present in the config objects you pass it, by design. That is safe when all config inputs are your own version-controlled files. Never merge in configuration built from untrusted sources at build time.
Should I scan build-time dependencies like webpack-merge?
Yes. Build tooling is part of your supply chain; a compromised build dependency can taint every artifact you ship. Scan devDependencies alongside runtime dependencies rather than treating build-only packages as out of scope.