require() vs import in Node.js: Understanding CommonJS and ES Modules

By the end of this page, you will understand why require() and import are not interchangeable in every Node.js project, how CommonJS and ES Modules differ, why errors like “has no default export” happen, and how to choose and configure the right module system for your project.

Node.js has used two module systems:

• CommonJS (CJS) uses require() and module.exports
• ES Modules (ESM) use import and export

They both solve the same problem: splitting code into reusable files and loading packages. But they use different syntax and have different rules.

CommonJS

CommonJS is the older module system in Node.js.

const express = require("express");

A module exports values like this:

module.exports = something;

or:

exports.myFunction = myFunction;

ES Modules

ES Modules are the standard JavaScript module system.

import express from "express";

A module exports values like this:

Think of modules like two different plug types.

• require() is one plug type: CommonJS
• import is another plug type: ES Modules

They both connect devices, but the shape of the plug is different.

Sometimes an adapter exists, so one can work with the other. Sometimes it does not fit cleanly, or you need extra configuration.

Another way to think about it:

• require() says: “Load this module in the old Node.js style.”
• import says: “Load this module in the standard JavaScript module style.”

If the module was packaged in a different style than your code expects, you get errors like:

• has no default export
• require is not defined
• Cannot use import statement outside a module

So the real issue is usually not the package itself. It is a module system mismatch.

CommonJS syntax

Importing

const express = require("express");
const fs = require("fs");

Exporting

function greet(name) {
  return `Hello, ${name}`;
}

module.exports = greet;

Using it:

const greet = require("./greet");
console.log(greet("Sam"));

ES Module syntax

Default export

export default function greet(name) {
  return `Hello, ${name}`;
}

Using it:

Consider this ES Module file:

import { readFile } from "fs/promises";

async function showFile() {
  const text = await readFile("message.txt", "utf8");
  console.log(text);
}

showFile();

Here is what happens step by step:

1. Node.js sees the import statement.
2. It checks whether the file is being treated as an ES Module.
   • This usually depends on file extension or package.json settings.
3. Node loads fs/promises and finds the named export readFile.
4. The showFile function is defined.
5. showFile() is called.
6. readFile("message.txt", "utf8") reads the file asynchronously.
7. await pauses inside the async function until the file is read.
8. The file contents are stored in .

Where require() is still used

• Older Node.js applications
• Legacy Express servers
• Existing codebases that were started before ESM became common
• Quick scripts copied from older tutorials

Example:

const mongoose = require("mongoose");
const express = require("express");

Where import is commonly used

• Modern Node.js applications
• Full-stack JavaScript projects
• Frontend frameworks like React, Vue, and Svelte
• Shared code that runs in multiple JavaScript environments

Example:

import express from "express";
import mongoose from "mongoose";

Practical situations where this matters

Building an API server

You may install Express, Mongoose, and dotenv. If your project uses ESM, all your imports should follow the ESM style consistently.

Writing utility modules

A helper file may export functions for validation, formatting, or database logic. You need matching import/export syntax across files.

In real projects, developers usually do one of these:

Pattern 1: Stay fully in CommonJS

This is common in older Node.js applications.

const express = require("express");
const mongoose = require("mongoose");
const dotenv = require("dotenv");

dotenv.config();

Why teams do this:

• stable in older codebases
• many existing files already use it
• avoids migration work

Pattern 2: Use ES Modules consistently

This is common in newer projects.

import express from "express";
import mongoose from "mongoose";
import dotenv from "dotenv";

dotenv.config();

Why teams do this:

• standard JavaScript syntax
• consistent with frontend code
• easier to share learning across environments

Common real-project patterns

Configuration loading

1. Mixing module systems without understanding the rules

Broken example:

import express from "express";
const mongoose = require("mongoose");

This can work in some setups, but it can also cause confusion or runtime errors depending on configuration.

Better approach:

• Use one module system consistently when possible.
• If your project is CommonJS, use require().
• If your project is ESM, use import.

2. Forgetting to enable ES Modules in Node.js

Broken example:

import express from "express";

If your project is not configured for ESM, Node may throw an error such as:

• Cannot use import statement outside a module

Fix:

• Add "type": "module" to package.json, or
• use the .mjs extension for ES module files

3. Confusing default exports and named exports

Quick rules

• require() = CommonJS
• import = ES Modules
• Do not assume they behave exactly the same
• In Node.js, ESM usually needs "type": "module" in package.json or .mjs files
• In ESM, local file imports usually include the file extension

CommonJS

const express = require("express");
module.exports = myFunction;

ES Modules

import express from "express";
export default myFunction;

Named exports

export const add = (a, b) => a + b;
import { add } from "./math.js";

Default exports

Why does require() work but import fails in Node.js?

Because your project may be using CommonJS by default, while import requires ES Module support and matching export rules.

How do I enable import in Node.js?

Add this to package.json:

{
  "type": "module"
}

Then use import/export syntax consistently.

Is import better than require()?

Not automatically. import is the modern JavaScript standard, but require() is still common in older Node.js codebases.

Why does Node.js say a package has no default export?

Because you used default import syntax, but the module does not expose a default export in the way your environment expects.

Can I mix require() and in the same project?

• module.exports — The CommonJS way to export values from a file.
• export default — The ES Module way to export one main value.
• named exports — Useful for exporting multiple values from one module.
• package.json — Controls whether Node.js treats files as CommonJS or ES Modules.
• Node.js module resolution — Explains how Node finds files and packages.
• Babel — Can transform module syntax and change how imports behave.
• TypeScript modules — TypeScript can add interop behavior that differs from plain Node.js.
• Express setup — A common place where developers first encounter require() vs import differences.