W
Wasp•3mo ago
PhilHalf

ERR_MODULE_NOT_FOUND - Relative paths

Wasp Version: 0.16.0 NodeJS Version: 22.13.0 OS: WSL Template: OpenSaaS I'm new to Wasp and NodeJS in general, but have been making some good progress on my project. However, I've tried to separate some of my logic into a shared file I'm now having problems when referencing files on relative paths. I have a file in src/queries/resellers.ts that has an import of: import { getUserAccessTree } from '../utils/accessTree'; The file does exist correctly at src/utils/accessTree.ts and VSCode can find the path with no errors. When I run Wasp though, I get the error: 
[ Server!] Error [ERR_MODULE_NOT_FOUND]: Cannot find module '<path_to_project>/app/.wasp/out/sdk/wasp/dist/ext-src/utils/accessTree' imported from <path_to_project>/app/.wasp/out/sdk/wasp/dist/ext-src/queries/reseller.js
[ Server!]     at finalizeResolution (node:internal/modules/esm/resolve:275:11)
[ Server!]     at moduleResolve (node:internal/modules/esm/resolve:932:10)
[ Server!]     at defaultResolve (node:internal/modules/esm/resolve:1056:11)
[ Server!]     at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:654:12)
[ Server!]     at #cachedDefaultResolve (node:internal/modules/esm/loader:603:25)
[ Server!]     at ModuleLoader.resolve (node:internal/modules/esm/loader:586:38)
[ Server!]     at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:242:38)
[ Server!]     at ModuleJob._link (node:internal/modules/esm/module_job:135:49) {
[ Server!]   code: 'ERR_MODULE_NOT_FOUND',
[ Server!]   url: 'file:///<path_to_project>/app/.wasp/out/sdk/wasp/dist/ext-src/utils/accessTree'
[ Server!] Error [ERR_MODULE_NOT_FOUND]: Cannot find module '<path_to_project>/app/.wasp/out/sdk/wasp/dist/ext-src/utils/accessTree' imported from <path_to_project>/app/.wasp/out/sdk/wasp/dist/ext-src/queries/reseller.js
[ Server!]     at finalizeResolution (node:internal/modules/esm/resolve:275:11)
[ Server!]     at moduleResolve (node:internal/modules/esm/resolve:932:10)
[ Server!]     at defaultResolve (node:internal/modules/esm/resolve:1056:11)
[ Server!]     at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:654:12)
[ Server!]     at #cachedDefaultResolve (node:internal/modules/esm/loader:603:25)
[ Server!]     at ModuleLoader.resolve (node:internal/modules/esm/loader:586:38)
[ Server!]     at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:242:38)
[ Server!]     at ModuleJob._link (node:internal/modules/esm/module_job:135:49) {
[ Server!]   code: 'ERR_MODULE_NOT_FOUND',
[ Server!]   url: 'file:///<path_to_project>/app/.wasp/out/sdk/wasp/dist/ext-src/utils/accessTree'
Technically this is correct based on the url specified at the bottom as there is no file called "accessTree" at that path, but there is an "accessTree.js" file along with "accessTree.d.ts" and "accessTree.js.map" Is there a proper structure I should be following for shared utility files like this or some configuration setting that I need for wasp to compile and reference it any differently?
4 Replies
kapa.ai
kapa.ai•3mo ago
Hi @PhilHalf. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- The error you're seeing (ERR_MODULE_NOT_FOUND) is due to how Node.js resolves ES module imports: when importing a file using a relative path without an extension (e.g., import { getUserAccessTree } from '../utils/accessTree';), Node.js expects the file to exist as-is, or as an index file in a directory, or with an explicit extension. In ES module mode, Node.js does not automatically resolve .ts or .js extensions unless they are specified in the import statement. This is a known issue in Wasp projects, especially after code is generated and compiled to JavaScript. The generated code expects the import to include the .js extension, but if your original TypeScript code omits it, the compiled output will have imports like import ... from '../utils/accessTree', which Node.js cannot resolve to accessTree.js without the extension. This leads to the ERR_MODULE_NOT_FOUND error you are experiencing. Key points from the knowledge sources: - If you import a file without an extension (e.g., ./util), it will not work in Node.js ES module mode, even though VSCode may not show an error. You must use the .js extension in your imports for the server-side code to work correctly after compilation. This is a quirk of the ES module system in Node.js, not specific to Wasp, but it affects Wasp projects because of how code is generated and compiled. The IDE may not catch this, but the runtime will fail to resolve the module if the extension is missing.
Example from the knowledge source: 
  import { helperFn } from './util.js' // WORKS
  import { helperFn } from './util'    // DOESN'T WORK
  
  import { helperFn } from './util.js' // WORKS
  import { helperFn } from './util'    // DOESN'T WORK
See discussion here - The error message you see is typical when the import path is missing the .js extension, and the solution is to always include the .js extension in your server-side imports in Wasp projects.
See further explanation here What you should do: Update your import statement in src/queries/resellers.ts to include the .js extension: 
import { getUserAccessTree } from '../utils/accessTree.js';
import { getUserAccessTree } from '../utils/accessTree.js';
This will ensure that, after compilation, the generated JavaScript code will have the correct import path that Node.js can resolve. Summary:
Always use the .js extension in your server-side imports in Wasp projects, even when writing TypeScript. This is necessary due to how Node.js resolves ES modules and how Wasp generates code. The IDE may not warn you, but the runtime will fail if the extension is missing. If you continue to have issues, double-check that the generated .js files exist in the expected output directory and that your import paths are correct relative to the compiled output structure. If you have further questions about project structure or configuration, let me know! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @PhilHalf, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
PhilHalf
PhilHalfOP•3mo ago
Thanks @kapa.ai, using the .js extension on the imports has resolved the problem. I'm coming from Angular, so I'm used to importing the modules without extensions
kapa.ai
kapa.ai•3mo ago
Let me check the knowledge base for you again. One moment! :books: ---------------------- You're welcome! Yes, this difference can be surprising if you're coming from Angular or other frameworks where omitting the extension is common. In Wasp (and more generally in Node.js ES module environments), you must include the .js extension in your server-side imports. This is due to how Node.js resolves ES modules and is not specific to Wasp—it's a quirk of the broader ecosystem and TypeScript's handling of module resolution. The IDE might not warn you, but the runtime will fail if the extension is missing, as you've experienced see discussion. If you stick to always including the .js extension in your server-side imports, you should avoid this issue going forward. If you run into any more Wasp-specific quirks, feel free to ask! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @PhilHalf, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
toticozeni
toticozeni•3mo ago
Glad you got it working 🎉

Did you find this page helpful?