Webpack "Cannot read properties of undefined (reading 'tap')"

By Daniel Zoghalchali·Latchkey

A plugin tried to tap into a Webpack compiler hook that is undefined for the Webpack version you are running. This is a version-mismatch between Webpack and one of its plugins or loaders.

What this error means

The build crashes during plugin setup with Cannot read properties of undefined (reading 'tap') (or the older Cannot read property 'tap' of undefined), with a stack pointing into a plugin. It is deterministic - a dependency/peer mismatch, not flake.

TypeError: Cannot read properties of undefined (reading 'tap')
    at SomeWebpackPlugin.apply (/app/node_modules/some-plugin/index.js:42:33)
    at /app/node_modules/webpack/lib/webpack.js:120:12

Diagnose it: is it resolution, transform, or memory?

Bundler failures in CI fall into three families and the error text often points at the wrong one. A module that resolves on your machine and not on the runner is nearly always case sensitivity or a missing optional dependency; a transform error is a config or version mismatch; and an unexplained kill with no stack is the out-of-memory reaper, not a build error at all.

# 1. resolution: does the file exist with EXACTLY that case?
git ls-files | grep -i "the/imported/path"

# 2. transform: what versions is CI actually resolving?
npm ls webpack vite rollup esbuild typescript 2>/dev/null | head -20

# 3. memory: was it killed rather than failed?
#    exit 137 = SIGKILL (OOM). Nothing in the bundler log will explain it.
node --max-old-space-size=4096 node_modules/.bin/vite build

Common causes

Plugin built for a different Webpack major

Webpack 5 reorganized hooks and dropped some that Webpack 4 plugins relied on. A plugin written for v4 reaches a hook that is undefined on v5 (or vice versa) and crashes calling .tap on it.

Mismatched/duplicate Webpack versions

A tool (CRA, Storybook, a framework) pins one Webpack version while a plugin pulls in another, so the plugin taps a compiler instance from a different Webpack copy.

How to fix it

Upgrade the plugin to match Webpack

Install the plugin release that supports your Webpack major version.

# example: a plugin's v5-compatible major
npm install some-webpack-plugin@latest
npm ls webpack   # confirm a single, matching webpack version

Deduplicate Webpack

1. Run npm ls webpack to find every Webpack version in the tree.
2. Align peers so there is one Webpack copy (dedupe, or pin via overrides/resolutions).
3. Re-install from a clean lockfile so the resolved tree is reproducible.

Make the build reproducible before you debug it

• Pin the Node major in setup-node and in engines. A bundler that resolves native bindings will pick a different prebuilt binary across majors.
• Delete node_modules locally and reinstall from the lockfile before concluding the runner is at fault; most "works locally" reports are stale local state.
• Set CI=true locally to reproduce. Several toolchains change behaviour under it, including treating warnings as errors.
• Exit code 137 is an out-of-memory kill. Raise --max-old-space-size or move to a larger runner rather than searching the bundler config.

How to prevent it

• Upgrade Webpack and its plugins/loaders together, not piecemeal.
• Keep a single Webpack version in the tree (npm ls webpack).
• Check a plugin's supported Webpack range before adding or bumping it.

Frequently asked questions

Related guides

References

• Node.js documentation
• npm CLI documentation
• GitHub Actions documentation