Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath is not defined by exports
Quick answer
The package defines an `exports` field in its package.json that doesn't list the deep path you're importing (e.g. `some-lib/dist/internal/thing`). Packages using `exports` block any subpath not explicitly declared there, even if the file physically exists — import from the package's documented public entry point instead.
What causes this error
The exports field in package.json is an allowlist. Once a package defines it, Node ignores the physical file layout entirely for resolution purposes — only the paths explicitly listed under exports can be imported from outside the package, everything else becomes a resolution error.
The Fix
// Wrong — reaching into a path the package doesn't expose
import { internalHelper } from 'some-lib/dist/internal/helper.js';
// Fix 1 — use the package's public entry point instead
import { helper } from 'some-lib';
// Fix 2 — check the package's exports map for a valid subpath export,
// e.g. some packages expose './utils' explicitly:
import { helper } from 'some-lib/utils';Common causes / variations
- Upgrading a package that recently added an `exports` field and locked down previously-open deep imports
- Copying an import path from an older tutorial or Stack Overflow answer written before the package added `exports`
- Relying on undocumented internal paths that were never meant to be public API
Related errors
See also: Cannot find module (missing extension in ESM), ERR_REQUIRE_ESM.
Was this fix helpful?
Comments
Loading comments...