Node developers using modern ECMAScript modules occasionally see the following runtime error when running or building a project:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/tokenize' is not defined by "exports" in package.json

This issue often has very few relevant search results even though it crops up in many projects. It happens when you import or require a module that isn’t explicitly exported by another package’s package.json file. This tutorial explains why the error occurs and how to fix it.

What causes ERR_PACKAGE_PATH_NOT_EXPORTED?

Since Node v12 the package exports field gives package authors control over which entry points consumers can import. When an exports field is defined, every other subpath in the package becomes private. The Node.js documentation states that if a module tries to import a path that hasn’t been defined in the exports field, Node throws Error [ERR_PACKAGE_PATH_NOT_EXPORTED]. In other words, you cannot require pkg/internal.js unless the package owner has explicitly exported that subpath.

This error can also occur after upgrading to a new version of Node. Some packages (especially those released before the exports field existed) may not be compatible with the latest Node versions. Upgrading Node without updating dependencies can therefore trigger the error.

How to fix the error

1. Use the latest LTS version of Node

Many developers reported that the error appeared after installing a cutting‑edge version of Node (such as v17 or v18). The accepted Stack Overflow answer recommends uninstalling the current version of Node and reinstalling the latest Long‑Term Support (LTS) release using nvm (Node Version Manager). This ensures that you’re using a stable version supported by most packages.

# Remove the current version and install the latest LTS
nvm uninstall node # or nvm uninstall <your‑current‑version>
nvm install --lts
nvm use --lts

After installing the LTS version, delete your node_modules directory and lock files (package‑lock.json or yarn.lock) and then reinstall dependencies:

rm -rf node_modules package‑lock.json yarn.lock
npm install

This step forces npm to rebuild your dependency tree using versions compatible with your Node LTS installation.

2. Update your import paths or package

If you are directly importing a private subpath (for example import { tokenize } from 'some‑package/lib/tokenize'), refactor your code to use the package’s public API. Check the package documentation or its exports section in node_modules/<pkg>/package.json to see what entry points are allowed. You may need to upgrade the package to a version that exports the functionality you need.

3. Modify the package (advanced)

In rare situations you might be working on a local package that lacks an exports entry and you control the code. Adding an exports field to the package’s package.json will define which files consumers can import. For example:

{
  "name": "my‑library",
  "version": "1.0.0",
  "exports": {
    "./utils": "./src/utils.js",
    "./tokenize": "./src/tokenize.js"
  }
}

This tells Node that my‑library/utils and my‑library/tokenize are valid entry points. Anything else will still throw ERR_PACKAGE_PATH_NOT_EXPORTED.

Conclusion

The ERR_PACKAGE_PATH_NOT_EXPORTED error means you’re trying to import a private module. Fix it by switching to Node’s latest LTS version, reinstalling dependencies and updating your import paths. If you maintain the package yourself, define the proper exports entries. Following these steps will eliminate the error and keep your project compatible with modern Node.js.