More detailed not_found error #260
Conversation
| @@ -105,7 +105,7 @@ module.exports = function resolveSync(x, options) { | |||
| if (n) return maybeRealpathSync(realpathSync, n, opts); | |||
| } | |||
|
|
|||
| var err = new Error("Cannot find module '" + x + "' from '" + parent + "'"); | |||
| var err = new Error("Cannot find module '" + x + "' from '" + parent + "'. Please verify that module installed, the package.json has 'main' field or module has index.js file"); | |||
There was a problem hiding this comment.
I'm a bit unclear what this is saying. What module should the user verify?
There was a problem hiding this comment.
ok - why is "installed" here? obviously you can't resolve anything that's not installed.
There was a problem hiding this comment.
I can remove this obvious part: Please verify that the module's package.json has 'main' field or it has index.js file
There was a problem hiding this comment.
I guess I’m wondering why all of this isn’t obvious. Modules must be installed to be resolved, and if it doesn’t have a “main” (explicit or implicit) then there’s nothing to resolve in the first place.
There was a problem hiding this comment.
As you can see on my example, it isn't obvious)
The case is: I have an installed module stretch-layout. It has neither index.js, nor main field in package.json. But it has module field in package.json (which is not even in spec yet) and it seems enough for bundler to resolve and build this module. And my point is that error "Cannot find module" is not precise enough, because there is module. But it's not prepared accurately. I think it's a bad pattern for that module, but it would be great if libraries like resolve, which are used by many other libraries, could detect error more precisely or even add support for module field, but it seems like more discussional change.
There was a problem hiding this comment.
The module field is both not standard, and also never ever will be - it's something a couple bundlers use that they never should have, and that no tooling should support by default.
Indeed, that library is broken, and given that it doesn't even have a repo link, a "main", or "exports", i'd suggest avoiding it entirely.
While I agree a better error message here might be helpful, it'd be being shown to the consumer, who has no ability to fix the situation - only to perhaps file an issue. That's not going to help you in this case, because this package has no way to do so.
Hello!
I added more detailed error in case of MODULE_NOT_FOUND.
Recently I had a problem with jest, which uses this package for searching dependencies. And there was this error. But I had module installed, I seen it with my eyes and could navigate to it via IDE. I spent several hours debugging the reason why it cannot be found. The reason was that module has no index.js file and
mainfield in package.json, so I just added alias. I believe that more detailed error text could help me.