Repository navigation
Missing useful debug information for Import "MODULE_NOT_FOUND" error #19783
Description
Hello there,
Node: v9.10.1
Platform: Darwin MACLTUS44977 15.6.0 Darwin Kernel Version 15.6.0
import { init: hello } from 'exists'
The above works as expected, in the sense that it is a syntax error and will throw a useful error denoting the filename and line number:
file:///Users/ctsuser1/Desktop/projects/app/index.mjs:1
import { init: hey } from 'kpn'
^
SyntaxError: Unexpected token :
at translators.set (internal/loader/Translators.js:27:13)
at <anonymous>
However, if the module does not exist:
import nonexistent from 'non-existent'
The error is fairly useless and it does not give any information about the filename or line number:
{ Error: Cannot find module 'non-existent'
at search (internal/loader/DefaultResolve.js:23:12)
at Loader.resolve [as _resolve] (internal/loader/DefaultResolve.js:60:11)
at Loader.resolve (internal/loader/Loader.js:50:18)
at Loader.getModuleJob (internal/loader/Loader.js:82:40)
at ModuleWrap.promises.module.link (internal/loader/ModuleJob.js:34:40)
at link (internal/loader/ModuleJob.js:33:36)
at <anonymous> code: 'MODULE_NOT_FOUND' }
I suspect this is along the same veins as (#19763), but not quite the same since it has nothing to do with the "Dynamic" importing functionality. Thanks in advance!
Activity
joyeecheung commentedon Apr 4, 2018
cc @nodejs/modules
devsnek commentedon Apr 4, 2018
@joyeecheung do you know of any way to make sure all our stack traces get decorated? the current approach has a lot of holes
joyeecheung commentedon Apr 4, 2018
@devsnek I have not looked into the ESM loader that much but to decorate the error here you'll probably need to change how/when the exceptions are thrown or handled during ESM loading. Throwing exceptions work for CJS because
requireis called by the modules so it will be on the stack anyway, but for ESM the modules don't call the loader so the loader will have to figure out the source positions and report the exceptions properly. Also--abort-on-uncaught-exceptiondoes not seem to work for ESM loaders at the moment either.devsnek commentedon Apr 4, 2018
@joyeecheung ah sorry i meant more like in general is there a way we can avoid calling the util method, maybe we can actually modify the stack on the c++ side? i'm wondering what kind of setup we can come up with to make decorating errors less ad-hoc in core
joyeecheung commentedon Apr 4, 2018
@devsnek In terms of reporting errors properly on the C++ side, you can take a look at
ReportExceptionin node.cc which is also used by the bootstrap code. But I am not sure in the context of ESM if you can get a proper error or TryCatch with the necessary source positions to pass into it.jdalton commentedon Apr 4, 2018
I would ❤️ an exposed util for loaders, instrumenters, and such to properly decorate their errors or let Node know not to pave-over others decorated errors.
devsnek commentedon Apr 4, 2018
@joyeecheung i was referring to how we pass decorated error stacks around with the symbols and stuff, like if we had a util that took care of it with every v8::TryCatch and didn't require calling anything from the js side, we wouldn't have the problem anymore. i am going to look into making a wrapper and hopefully get somewhere 🤞
m-a-r-c-e-l-i-n-o commentedon Apr 4, 2018
@jdalton @devsnek @joyeecheung Thanks for timing in. I know this sounds a bit crazy, but I'm hoping to be able to use ES modules in production in a enterprise setting within the next two months. As far as I can tell, not having proper debug messages for ES modules has been the only drawback in my setup. Getting unit test with coverage to work with ES modules was also a major challenge, but even that has been resolved. Would hate to have to go back to CommonJS for the release. Really hoping you guys can make some progress on this. If there is anything I can do, I will. Thanks in advance!
jdalton commentedon Apr 4, 2018
@m-a-r-c-e-l-i-n-o
I'd caution against using experimental features in production enviros (esp. enterprise ones).
m-a-r-c-e-l-i-n-o commentedon Apr 4, 2018
@jdalton
Haha, I'm sure the engineering community has felt an earthquake like disturbance as I wrote that statement. Thank you for your thoughts. It's obviously something I'm concerned about, but refactoring to CommonJS doesn't look promising either (maybe transpiling would be a viable backup plan). When I got into it, I was secretly hoping that ES modules would be stable in Node 10, which is scheduled to be released this month, but it looks like I'm just kidding myself, aren't I?
BridgeAR commentedon Jan 2, 2020
The new error message is
Error: Cannot find package 'non-existent' imported from /home/ruben/repos/node/node/t.mjs. This seems like a significant improvement over the former state.I am therefore closing this as resolved. If that's not enough, please leave a comment to reopen.