DEV Community

Cover image for What Happens When You Run `npm run dev`

What Happens When You Run `npm run dev`

Athreya aka Maneshwar on May 19, 2026

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git...
Collapse
 
aloisseckar profile image
Alois Sečkár

Since Vite 8 esbuild is no longer used but rolldown. But I guess it conceptually still does the same thing.

Collapse
 
lovestaco profile image
Athreya aka Maneshwar

Yupp

Collapse
 
tahosin profile image
S M Tahosin

This is a fantastic deep dive! It's so easy to take the magic of npm run dev and tools like Vite for granted. Breaking down the step-by-step process of module resolution really highlights how much performance we gain by serving native ES modules during development. Thanks for this clear breakdown!

Collapse
 
lovestaco profile image
Athreya aka Maneshwar

Thanks bud!

Collapse
 
lcmd007 profile image
Andy Stewart

What a phenomenal breakdown! From OS-level process spawning and Vite’s pre-bundling with esbuild, to native ESM dependency trees and React Fast Refresh state preservation—this completely demystifies the entire lifecycle behind npm run dev.

This "no-bundle, on-demand transformation" philosophy represents the absolute pinnacle of local-first, ultra-responsive engineering. It’s exactly the kind of hardcore systems thinking we need when architecting next-generation development tools and localized infrastructure. Brilliant write-up!

Collapse
 
lovestaco profile image
Athreya aka Maneshwar

Thanks bud!

Collapse
 
neithergalax profile image
neither galax

Thanks for taking us through the npm journey. This came in a perfect timing.
I've run npm run dev command 1 time in my life, today. I just downloaded the module to work on ts based project I am trying to contribute on. It's always fun to learn how the system is actually working.

Collapse
 
lovestaco profile image
Athreya aka Maneshwar

Thanks buddy!

Collapse
 
motedb profile image
mote

Great breakdown of the Node module resolution chain. I spent half a day debugging a module not found error that turned out to be a shadowed node_modules in a monorepo package -- the resolution was finding the wrong version because of how the workspace hierarchy interacted with NODE_PATH.

One thing that's always tripped me up: the interaction between exports field in package.json and the old main/module fields. If a package has exports defined, it completely bypasses the file-system resolution, which means files that should be reachable via main suddenly 404 if you don't include the exact export mapping.

Do you use any tooling to visualize or debug these resolution paths? Or just build intuition over time?

Collapse
 
samuraix13 profile image
SamuraiX[13~]

This was such a fun and interesting article to read, thanks for teaching me something new :D

Collapse
 
lovestaco profile image
Athreya aka Maneshwar

Thanks buddy :)