I’m encountering a problem with my Node.js application that won’t start correctly. Whenever I execute my start command, it throws up an error stating that it cannot locate a module that I know is present in my project.
Here’s the output I see when I try running the command:
user@User:~/myapp$ npm run start
> start
> node src/main.js
node:internal/modules/esm/resolve:274
throw new ERR_MODULE_NOT_FOUND(
^
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/home/user/myapp/src/utils/config' imported from /home/user/myapp/src/main.js
at finalizeResolution (node:internal/modules/esm/resolve:274:11)
at moduleResolve (node:internal/modules/esm/resolve:859:10)
at defaultResolve (node:internal/modules/esm/resolve:983:11)
at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:783:12)
at #cachedDefaultResolve (node:internal/modules/esm/loader:707:25)
at ModuleLoader.resolve (node:internal/modules/esm/loader:690:38)
at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:307:38)
at ModuleJob._link (node:internal/modules/esm/module_job:183:49) {
code: 'ERR_MODULE_NOT_FOUND',
url: 'file:///home/user/myapp/src/utils/config'
}
Node.js v22.18.0
I am working on Ubuntu using VSCode, and I’ve checked that both npm and Node.js are up to date. The file I am trying to import is definitely located correctly. Has anyone else faced this kind of problem?
This exact issue drove me crazy for hours until I figured out it was the file extensions. Since you’re using ES modules in Node.js, you need to add .js to your import. Change ./utils/config to ./utils/config.js. ES modules require explicit file extensions for local imports - unlike CommonJS where you could skip them. Also check that your package.json has "type": "module" or make sure your file uses .mjs extension. Node.js won’t automatically resolve file extensions here, so it’s looking for the exact path you specified.
Check your import syntax in main.js. You’re probably missing the file extension or using the wrong relative path. I had this exact error - I was using import config from 'utils/config' instead of import config from './utils/config.js'. You need that dot-slash for relative imports in ES modules. Also make sure your config file actually exports something. Empty files or missing export statements cause this error even when the file exists. Drop a console.log at the top of your config file to see if Node can read it during import.
check if your package.json has "type": "module" - you need it for import statements. without it, Node defaults to CommonJS and throws errors. also verify the config file actually exists at that path. sometimes VS Code shows unsaved files that aren’t on disk yet.
Had this exact problem last month and wasted hours debugging it. Node’s treating your code as ES modules but can’t find the import path. Check your import in main.js - you need the full relative path with extension like import config from './utils/config.js'. Make sure config.js actually exports something with export default or named exports. Sometimes the file’s there but has zero exports, which breaks everything. Also check file permissions - I’ve seen Node fail to read files on Linux because of permission issues.
Everyone’s suggesting manual fixes, but this is a workflow issue that’ll keep happening. I’ve watched this module resolution mess kill productivity on tons of projects.
Yeah, adding .js extensions works now, but what about next week? Someone adds an import without the extension, or you refactor file paths - boom, same debugging hell all over again.
I automate the whole dev pipeline instead. Built a Latenode workflow that watches my codebase for import issues, validates module paths as I code, and fixes common ES module problems before they break anything.
It checks file extensions, validates exports actually exist, runs linting rules, and restarts the dev server when stuff gets fixed. No more digging through Node.js error stacks or manually hunting down broken import paths.
Catches problems while you’re coding instead of at runtime. Your team never sees this error again because it gets prevented automatically.
You’re right about the file extension issue, but there’s a smoother way to handle this. I’ve hit similar Node.js module resolution problems tons of times - they usually mean there’s a bigger workflow issue.
I stopped constantly debugging import paths and module configs. Now I automate the whole dev process. When these errors pop up, I use Latenode to set up workflows that handle file watching, dependency checking, and auto-restarts when modules break.
For your case, you can create a Latenode workflow that watches your src directory, validates imports automatically, and catches missing extension errors before you run anything. It handles environment setup, runs tests, and deploys everything.
Once it’s set up, you never manually debug module resolution again. Everything works, and you can build features instead of fighting Node.js quirks.