What is the purpose of `__dirname` and `__filename` in Node.js?

Q: What is the purpose of `__dirname` and `__filename` in Node.js?

**Target Audience:** Engineers preparing for Node.js phone screens — assumes very basic file-path familiarity. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The values below were printed from a **real file on disk**, deliberately not from `node -e`, which was checked first and produces misleading placeholder values instead. ## 1. Why This Even Matters — A Story First A person gives directions as "the store two blocks from here" — which only makes sense if "here" is fixed and known. If "here" secretly means "wherever the person happens to be standing when they say it," the same sentence points to a different store every time depending on where the speaker was standing, which is exactly the bug a relative file path has when it silently depends on the process's launch directory instead of the file's own location. ## 2. The Core Idea 📌 **Interview term:** `__dirname` and `__filename`

The problem

Question presented to candidate: "Your code does fs.readFileSync('./config.json') and it works when you run it from the project root, but breaks when a teammate runs it from a different directory. What went wrong, and what should you have used instead?"

What a strong answer should cover:

__dirname and __filename are two of the five parameters supplied by Node's implicit CommonJS module wrapper — the current module file's absolute directory path and absolute file path, respectively.
📌 The bug they fix: a relative path like ./config.json is resolved against the process's current working directory (wherever the node command was actually invoked from), not against the file's own location. path.join(__dirname, "config.json") is resolved against the file's own location, which is what most code actually means when it says "the config file next to me."
__dirname/__filename exist only in CommonJS files — in an ES Module, there is no such implicit variable; the equivalent is derived from import.meta.url (typically via fileURLToPath(import.meta.url) and path.dirname(...) of that).
Running code with node -e "..." or via the REPL produces misleading placeholder values for these (. and [eval]) rather than a real path — a good answer notes this rather than testing/demonstrating the concept that way and drawing the wrong conclusion from it.
process.cwd() is the commonly confused alternative — it returns the current working directory of the process, which changes based on how and from where the script was launched, and is a fundamentally different, session-dependent value from a file's own fixed location.
A precise answer names the practical rule: any path meant to be relative to the source file itself (a config file shipped next to the code, a template, a static asset) should be built with __dirname/import.meta.url, never a bare relative string — those are the correct tool only for a path meant to be relative to wherever the process happens to be invoked from.

Clarifying questions expected:

"Is this CommonJS or an ES Module?" — the mechanism (implicit variable vs. import.meta.url) differs.
"Does the path actually need to be relative to the invoking directory, or to the source file?" — this is the real distinction the bug in the prompt is about.

Code / implementation expected: Yes — showing the actual absolute values from a real file, and the ESM equivalent via import.meta.url, is the concrete deliverable.

global variables
paths
modules
commonjs

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js phone screens — assumes very basic file-path familiarity. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The values below were printed from a real file on disk, deliberately not from node -e, which was checked first and produces misleading placeholder values instead.

1. Why This Even Matters — A Story First

A person gives directions as "the store two blocks from here" — which only makes sense if "here" is fixed and known. If "here" secretly means "wherever the person happens to be standing when they say it," the same sentence points to a different store every time depending on where the speaker was standing, which is exactly the bug a relative file path has when it silently depends on the process's launch directory instead of the file's o

The solution is hidden so you can try first

6 min read · 8 sections

Read the code

JavaScriptReal __dirname/__filename values from an actual file, the bug they fix, and the ESM equivalent

// dirtest.cjs — run as: node dirtest.cjs
console.log("__dirname:", __dirname);
console.log("__filename:", __filename);
// __dirname: C:\...\node-batch5
// __filename: C:\...\node-batch5\dirtest.cjs

// BROKEN — depends on wherever "node" was invoked from:
const data = fs.readFileSync("./config.json");
// CORRECT — anchored to this file's own fixed location:
const data2 = fs.readFileSync(path.join(__dirname, "config.json"));

// The ES Modules equivalent (no __dirname/__filename there):
import { fileURLToPath } from "node:url";
import path from "node:path";
const __filenameESM = fileURLToPath(import.meta.url);
const __dirnameESM = path.dirname(__filenameESM);

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

What is the purpose of `dirname` and `filename` in Node.js?