# Node.js ERR_PACKAGE_PATH_NOT_EXPORTED - Fix Subpath Not in "exports"

> Fix Node.js ERR_PACKAGE_PATH_NOT_EXPORTED "No exports main / subpath … is not defined" in CI - a deep import a package’s "exports" map no longer allows.

Source: https://latchkey.dev/learn/node-js/node-err-package-path-not-exported  
Updated: 2026-06-25

When a package declares an `exports` field, Node treats it as the complete public API. Any subpath not listed there is blocked, even if the file physically exists in node_modules.

## Diagnose it: what is different about the runner?

A build that passes locally and fails on a runner differs in a small number of predictable ways. Check those before changing build configuration, because the build config is usually not the thing that changed.

```.github/workflows/ci.yml
- run: |
    node --version && npm --version
    echo "NODE_ENV=$NODE_ENV  CI=$CI"
    nproc && free -h && df -h /
    ls -la node_modules/.bin | head
```

> `CI=true` is set on every runner and changes behaviour in several toolchains, most commonly by promoting warnings to errors. Reproduce locally with `CI=true npm run build` before assuming the runner is broken.

## The three that account for most of them

- **Case sensitivity.** Linux runners are case sensitive, macOS is not. An import with the wrong case resolves locally and fails in CI.
- **Out of memory.** Exit code 137 is a SIGKILL from the kernel, not a build error. Raise `--max-old-space-size` or use a larger runner.
- **devDependencies pruned.** `NODE_ENV=production` makes `npm ci` skip devDependencies, so the build tool itself goes missing. Set it after install, not before.

## FAQ

### What causes Node.js ERR_PACKAGE_PATH_NOT_EXPORTED?

There are 2 common causes: deep-importing a path the package no longer exports and importing the bare package without a defined main. A package added or tightened its exports map, so reaching into its internals (a path that used to resolve) is now blocked.

### How do I fix Node.js ERR_PACKAGE_PATH_NOT_EXPORTED?

There are 2 fixes depending on which cause you have: import only the package’s public entry points and if you truly need an internal path. Work through them in order, since the first is the most common.

### What does Node.js ERR_PACKAGE_PATH_NOT_EXPORTED actually mean?

An import or require of a deep path inside a dependency (e.g.

### How do I stop Node.js ERR_PACKAGE_PATH_NOT_EXPORTED happening again?

Depend only on documented entry points, never package internals. The prevention section lists 3 changes that keep it from recurring.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt