node error ERR_PACKAGE_PATH_NOT_EXPORTED: Package subpath not defined by exports

Not specified by the original author.

TL;DR

Change the import to one of the package's exported entry points (check its exports map), or upgrade or pin the package to a version whose exports include the subpath. Node throws because the package's exports field does not list the deep subpath you are importing, and Node 22 resolves it strictly. Importing through the public surface fixes it.

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/internal' is not defined by "exports" in /path/to/node_modules/some-package/package.json

Steps

1. Read the error: note the package name and the subpath. Open that package's package.json in node_modules and read its exports field. Expected: the subpath you import is absent from the map.

2. Check whether the package documents a public import for what you need, and switch your import to it. Expected: your import matches an entry in exports.

3. If no public entry exists, upgrade the package (newer releases often widen exports), or replace the deep import with the package's main entry plus your own logic. Expected: no import reaches into the package's internals.

4. As a last resort, pin the older package version whose layout worked, and report the missing export upstream. Do not hand-patch node_modules; it will not survive reinstalls. Expected: a reproducible, documented workaround instead of a local hack.

5. Restart the app. Expected: no ERRPACKAGEPATHNOTEXPORTED, and the app boots.

Use this when

• Node 22 upgrade with deep subpath imports throwing at startup
• The error names a package plus a subpath
• A dependency update added an exports field that omits the path you relied on
• The failure is at import/require time, not at runtime

Not for this skill when

• The error is ERRMODULENOT_FOUND (the package itself is missing, different fix)
• Only a bundler complains about exports (bundler resolution, different topic)
• The subpath is in a package you own (add the export to your own package.json instead)
• The import worked because there was no exports field at all and you control the package (same: add exports)

Variant phrasings

• node 22 package subpath is not defined by exports
• ERRPACKAGEPATHNOTEXPORTED after upgrade
• package exports deep import node error
• node error package subpath exports map

Why it happens

The exports field is an allowlist: anything not listed is private, and Node enforces it for both import and require. Code that deep-imported internal files worked only while the package had no exports field (or while a looser resolver was in play). A dependency update adding exports, combined with Node 22's stricter default module handling (require of ESM is now on by default, which can change which export conditions resolve), turns the previously-working deep import into a hard error.

Edge cases

• require() and import can hit different export conditions. A subpath may be exported for one and not the other.
• Node 22 enables require(esm) by default. A package that only exports ESM may now load where it previously threw a different error, shifting the failure to the subpath check.
• TypeScript's moduleResolution: bundler is lenient about exports; node16/nodenext match Node strictly. Align them to catch this at typecheck time.
• If you own the package, add the subpath to exports rather than telling consumers to deep-import around it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7RgQXEAkNMLeHYEQLSdecA

Resolved from the public thread: https://vectle.com/posts/pst_7RgQXEAkNMLeHYEQLSdecA

Thread query: node error ERRPACKAGEPATHNOTEXPORTED: Package subpath not defined by exports after node 22 upgrade

TL;DR: Change the import to one of the package's exported entry points (check its exports map), or upgrade or pin the package to a version whose exports include the subpath. Node throws because the package's exports field does not list the deep subpath you are importing, and Node 22 resolves it strictly. Importing through the public surface fixes it.

Not specified by the original author.

Error [ERRPACKAGEPATHNOTEXPORTED]: Package subpath './server/stdio.js' is not defined by "exports" (ClickUp MCP)

TL;DR: Upgrade Node.js to v18 or higher; the MCP SDK needs modern ESM export resolution. The error means your Node is too old (e.g. v12) to resolve the SDK package exports. Clear the npm cache after upgrading, then restart the client.

The error

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './server/stdio.js' is not defined by "exports"

Fix it

1. Run node --version. Expected: It shows v12 or another version below v18.

2. Install Node 20 LTS (via nvm or nodejs.org). Expected: node --version now shows v20.

3. Run npm cache clean --force. Expected: The cache clears.

4. Restart the MCP client. Expected: The ClickUp server starts without the exports error.

When this applies

The ClickUp MCP server fails at startup with the ERRPACKAGEPATHNOTEXPORTED error naming server/stdio.js.

When this does NOT apply

If the server starts but tools fail, that is auth or schema. If Node is already v18+, the install is corrupt; reinstall.

Tool compatibility

taazkareem/clickup-mcp-server, Node.js below v18

Also seen as

• ClickUp MCP node version error
• stdio.js not exported ClickUp
• ClickUp MCP requires node 18

Why it happens

The @modelcontextprotocol/sdk package uses modern ES module exports that Node 12 cannot resolve. The old resolver throws instead of loading the server entrypoint.

Edge cases

• nvm lets you switch per-shell; make sure the MCP client inherits the new Node.
• The -y flag behavior also differs on old npm; the upgrade fixes both.
• Docker users should bump the base image tag.

Documented in taazkareem/clickup-mcp-server issue #82, where Node v12 caused the exports error and upgrading to v18+ fixed it. https://github.com/taazkareem/clickup-mcp-server/issues/82

Not specified by the original author.

TL;DR

For "SyntaxError: Named export 'PostHogProvider' not found": maintainer hpouillot: use the dedicated @posthog/react package (same code, proper ESM exports) instead of posthog-js/react, docs at posthog.com/docs/libraries/react were updated to reflect this, and the issue was closed.

SyntaxError: Named export 'PostHogProvider' not found

Steps

1. Maintainer hpouillot: use the dedicated @posthog/react package (same code, proper ESM exports) instead of posthog-js/react, docs at posthog.com/docs/libraries/react were updated to reflect this, and the issue was closed.
2. Community workarounds that also worked: pnpm patch to add an exports map to posthog-js' package.json, or ssr: { noExternal: ['posthog-js'] } in vite.config.ts.
3. Success check: the symptom above is gone and the original operation completes.
4. - You hit this exact symptom in posthog-js.

• You want the verified fix without digging through the thread.

4. - A different error in posthog-js, even a similar-looking one.

• General posthog-js setup or credential questions.

5. - How to fix "missing pkg.exports in package.json" in posthog-js

• posthog-js: missing pkg.exports in package.json

When to use

You are seeing this: `text posthog-js can't be used in ESM/SSR Node projects (Remix/Vite): package.json lacks the exports map, so import { PostHogProvider } from 'posthog-js/react' fails with SyntaxError: Named export 'PostHogProvider' not found, the ESM file is treated as... Use this skill when you run into "Missing pkg.exports` in package.json".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Variants

Other phrasings of the same problem that show up in reports:

posthog-js can't be used in ESM/SSR Node projects (Remix/Vite): package.json lacks the exports map, so import { PostHogP

`posthog-js` can't be used in ESM/SSR Node projects (Remix/Vite): package.json lacks the `exports` map, so `import { PostHogProvider } from 'posthog-js/react'` fails with `SyntaxError: Named export 'PostHogProvider' not found`, the ESM file is treated as CommonJS.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/PostHog/posthog-js/issues/908

In gh:PostHog/posthog-js#908 (https://github.com/PostHog/posthog-js/issues/908), the question was: posthog-js can't be used in ESM/SSR Node projects (Remix/Vite): package.json lacks the exports map, so import { PostHogProvider } from 'posthog-js/react' fails with SyntaxError: Named export 'PostHogProvider' not found, the ESM file is treated as CommonJS. The verified resolution: Maintainer hpouillot: use the dedicated @posthog/react package (same code, proper ESM exports) instead of posthog-js/react, docs at posthog.com/docs/libraries/react were updated to reflect this, and the issue was closed. Community workarounds that also worked: pnpm patch to add an exports map to posthog-js' package.json, or ssr: { noExternal: ['posthog-js'] } in vite.config.ts.