Typical errors that occur when module types mismatch

The following error indicates that you are attempting to use the require() statement to import an ECMAScript Module (ESM) in a context where CommonJS is expected. This error typically occurs when there is a mix of module types in your Node.js project, so if you are using ESM in your project (e.g., by setting "type": "module" in package.json or using .mjs file extension), you should consistently use import and export syntax throughout your codebase.

(node:26444) [ERR_REQUIRE_ESM] Error Plugin: xyz [ERR_REQUIRE_ESM]: require() of ES Module C:\code\xyz\node_modules\somepackage\lib\somepackage.js from C:\code\xyz\dist\index.js not supported.
Instead change the require of somepackage.js in C:\code\xyz\dist\index.js to a dynamic import() which is available in all CommonJS modules.

Here’s an example of how this error might occur:

// somepackage.js - ESM module
export const someFunction = () => {
  console.log('This is an ESM module.');
};

Next, we make the mistake of using require to import ESM module in CommonJS module:

// index.js - CommonJS module
const somePackage = require('somepackage'); // This line would trigger the error

somePackage.someFunction();

To fix this either ensure that your entire codebase uses the same module type: Either convert your project to CommonJS by removing "type": "module" from package.json (or renaming .mjs files to .js), or convert the entire project to ESM by ensuring that all files use import and export syntax.

If you want to keep the mixed module types, you can use dynamic import to load the ESM module:

// index.js - CommonJS module
const somePackage = await import('somepackage');

somePackage.someFunction();

Error: Cannot use import statement outside a module

Cannot use import statement outside a module

This error mainly occurs when you use the import keyword to import a module in a file that Node.js does not recognize as an ECMAScript module. Or when you omit the type="module" attribute in a script tag.

  • If your project is intended to use ESM but lacks the "type": "module" field in package.json, Node.js will treat files with .js extensions as CommonJS by default.
  • To use ESM, either change the extension to .mjs or set "type": "module".

Error: TypeError: Class constructor X cannot be invoked without 'new'

That error typically happens when ESM class syntax (compiled to native ES classes) is executed in a CommonJS environment that tries to treat it like an old-style function.

Let’s look at a minimal reproducible example.

1. The ES Module class (e.g. esm-lib.js)

// esm-lib.js
export class MyClass {
  constructor() {
    console.log('MyClass constructed');
  }
}

This is valid ESM syntax. It must be imported using import, not require.


2. A CommonJS script trying to require it (e.g. cjs-app.js)

// cjs-app.js
const { MyClass } = require('./esm-lib.js');

function BrokenSubclass() {
  // try to call parent class constructor
  MyClass.call(this); // ❌ this will fail
}

BrokenSubclass.prototype = Object.create(MyClass.prototype);
BrokenSubclass.prototype.constructor = BrokenSubclass;

new BrokenSubclass();

3. Run it (Node < 20 or without "type": "module" in package.json)

node cjs-app.js

You’ll get:

TypeError: Class constructor MyClass cannot be invoked without 'new'

Why it happens

When Node’s CommonJS loader (require) imports an ESM file, it doesn’t automatically transpile or downlevel its class syntax.
The ES class is not a function constructor — it cannot be called like a regular function (using .call() or .apply()), only with new.

CommonJS “inheritance” patterns like this one:

Parent.call(this)

work with pre-ES6 constructor functions, not ES classes.

4. How to fix it

Either:

  • Use native ESM everywhere: // app.mjs import { MyClass } from './esm-lib.js'; class WorkingSubclass extends MyClass { constructor() { super(); console.log('Subclass ok'); } } new WorkingSubclass();
  • Or convert the imported ES class into a CJS-compatible constructor (not recommended).

In short: the error is Node reminding you that ES classes are real classes, not fancy functions — and CommonJS’s old call/apply inheritance patterns can’t touch them.

About Author

Mathias Bothe To my job profile

I am Mathias from Heidelberg, Germany. I am a passionate IT freelancer with 15+ years experience in programming, especially in developing web based applications for companies that range from small startups to the big players out there. I create Bosycom and initiated several software projects.