ESM build fails with ERR_UNSUPPORTED_DIR_IMPORT in Node.js 22

[HavenCTO]

When importing @nucypher/taco in a native ESM project ("type": "module"), the package fails to load with:

Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import '.../node_modules/@nucypher/taco/dist/es/conditions' is not supported resolving ES modules imported from .../node_modules/@nucypher/taco/dist/es/index.js

Environment:

Node.js v22.22.0
@nucypher/taco@0.7.0-alpha.12
Project using "type": "module" in package.json - https://github.com/HavenCTO/lmstudio-bridge
Root cause:

The ESM build at dist/es/index.js contains imports without file extensions, e.g.:

import ... from './conditions' // missing ./conditions/index.js
Node.js ESM requires explicit file extensions for imports. This works in bundlers (webpack, esbuild, vite) because they resolve paths automatically, but fails in native Node.js ESM.

Relevant spec: Node.js ESM — Mandatory file extensions

Suggested fix:

Either:

Update the TypeScript build for ESM to emit imports with full file paths (configure moduleResolution: "node16" or "nodenext" and ensure imports include .js extensions in source)
Or use a bundler that outputs spec-compliant ESM with extensions
Workaround:

Consumers can force CJS resolution by patching package.json exports:

"exports": {
  ".": "./dist/cjs/index.js"
}

[theref]

Thanks for the detailed report — this is a legit gap. Our ESM build is pure tsc output which doesn't add file extensions to relative imports, so it works through bundlers (webpack, vite, etc.) but breaks in native Node.js ESM as you found.

The fix would be switching the ESM build from raw tsc to something like tsup that emits spec-compliant ESM with proper import paths. We'll need to validate it against our existing examples and test suite before shipping.

Your CJS workaround is solid in the meantime.

[HavenCTO]

Thanks for confirming. Any rough timeline on when this might land?