Tagged: esm
Error [ERR_REQUIRE_ESM]: require() of ES Module not supported
You're using require() on a package that only ships ES Modules (it declares "type": "module" or only exports .mjs). Either switch your file to ESM and use import, or use a dynamic import() instead of require().
Error [ERR_MODULE_NOT_FOUND]: relative import is missing its file extension
Node's native ESM resolver requires fully specified relative import paths, including the extension — `import './utils'` fails; it must be `import './utils.js'`. This trips people up constantly when migrating a CommonJS or bundler-based project to native ESM.
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath is not defined by exports
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.
TS1484: 'X' is a type and must be imported using a type-only import when verbatimModuleSyntax is enabled
With `verbatimModuleSyntax` enabled, TypeScript no longer decides for you whether an import is type-only or a real runtime import — it emits imports exactly as written. If you import something that's only ever used as a type, you must write `import type { X }` explicitly, since a regular `import { X }` would try to import a non-existent runtime value.